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THE  INTEGRATED  LIBRARY  SYSTEM: 


DESIGN  CONCEPTS  FOR 


A  COMPLETE  SERIALS  CONTROL  SUBSYSTEM 


The  Integrated  Library  System  (ILS),  originally  design  and 
develbped  by  the  National  Library  of  Medicine's  Lister  Hill 
Center,  is  a  state-of-the-art  minicomputer  based  library 
automation  package.  It  is  fully  integrated  by  both  design  and 
function.  The  serials  control  subsystem  is  one  of  the  last  major 
processing  units  to  be  developed.  This  document  presents  design 
concepts  and  detail  which  will  be  followed  by  Online  Computer 
Systems,  Inc.  t6  implement  the  serials  subsystem  for  the  Pentagon 
Library.  The  reader  is  referred  to  a  previous  document,  THE 
INTEGRATED  LIBRARY  SYSTEM:  FUNCTIONAL  REQUIREMENTS  FOR  A  COMPLETE 
SERIALS  CONTROL  SUBSYSTEM,  for  the  statement  6f  scope  and 
requirements  bf  the  subsystem. 

The  new  serials  control  subsystem  will  privide  the  following 
functional  capabilities: 

Expansion  of  the  serials  holding  record 

User-defined  enumeration  and  chronology  f6r  each  title 
Multiple  formats  for  each  title 
Parameterized  claiming  and  binding  per  title 
Generalized  date  formats 

Check-in  of  serial  issues 

Elimination  of  ILS  scratch  files 

Single  stroke  check-in,  if  at  all  possible 

Use  of  prediction  algorithms 

Optional  printing  of  barcode  labels 

Automatic  updating  of  the  consolidated  holdings  data 

User  alerts  for  claiming  and  binding 

Ability  to  analyze  checked-in  volumes 

Claiming  serials  issues 

Prediction  of  next  issue 
Automatic  claim  notification 
Automatic  holdings  data  update 
Manual  intervention  and  Overrides 
Interface  with  a  vendor  file 
Local  parameters  for  system  and  titles 
Online  review  and  edit  of  claims 
MIS  data  on  vendor  performance 
Notice  generation 


Routing  of  individual  issues 

Generation  of  a  routing  slip  upon  check-in 
User-defined  routing  slips 
Maintenance  of  routing  queues 

Binding  control 

Automatic  binding  notification 
Notice  generation 
Bindery  tracking 
Overdue  management 

Replacement  of  issue  barcodes  with  volume  barcodes 
Transfer  Of  usage  statistics 

Automatic  update  of  consolidated  holdings  data 
Management  of  microfilm  subscriptions 
CAS  display  of  bindery  status 
Online  review  and  edit  of  bindery  notices 
MIS  data 

CAS  updgrades 

Redefined  CAS  screens  for  serials 
Expanded  item  statuses 

Automatic  update  of  consolidated  holdings  data 

Expanded  item  100k-up  routines 

Indexes  to  include  Coden,  ISSN,  title  key,  corporate 
author,  call  number,  and  title 

MIS  data  and  notice  generation 
Vendor  performance  report 
Claiming  activity  report 
Bindery  activity  report 
Check-in  activity  report 
Routing  slip  generation 
Claim  notice  generation 
Bindery  notice  generation 
Overdue  bindery  notice  generation 
Pre-claim  report 
Unfilled  claims  report 
Bindery  candidates  report 
Journal  holdings  list 

Centralized  vendor  file 

Add,  edit,  and  deletion  of  vendor  records 
Link  to  titles,  claims,  and  bindery  records 
Use  of  PMS  software 

Conversion  of  present  holdings  for  the  Pentagon  Library 
Hooks  for  future  links  to  an  acquisitions  subsystem 
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All  of  the  above  points  were  addressed  in  the  previous 
requirements  document.  This  document  details  the  design  issues 
and  concepts  involved  in  each  major  processing  area. 

One  of  the  basic  underlying  assumptions  Of  our  design  work  is 
that  the  new  file  structures  should  be  as  compatible  as  possible 
with  the  MARC  FORMAT  FOR  HOLDINGS  AND  LOCATIONS.  Although 
this  format  has  been  finalized  only  recently,  we  believe  that 
the  MARC  format  will  be  the  nationally  accepted  standard  for 
serial  data.  The  ILS  serials  subsystem  will  be  compatible  with 
the  853  field  in  particular.  The  internal  ILS  data  structures 
will  be  mappable  both  into  and  from  the  MARC  format  by 
manipulation  modules.  A  future  enhancement  may  provide  tape 
reading  and  writing  from  and  to  the  MARC  format  for  holdings, 
but  that  will  not  be  provided  in  the  initial  development  cycle. 
We  will  assure  data  compatibility  with  a  core  subset  of  data 
elements  (described  in  this  document  under  the  HOLDINGS  ADD/EDIT 
section) . 
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FUNCTIONS  AND  JOBS  NEEDED  IN  THE  NEW  SERIALS  CONTROL  SUBSYSTEM 


PP  SERIALS  SUBSYSTEM  PARAMETERS 
HA  HOLDINGS  ADD/EDIT 
SE  SERIALS  CHECK-IN 

BQ  BINDERY  INSTRUCTION  RECORD  DEFINITION 
BA  BINDERY  INSTRUCTION  RECORD  ADD/EDIT 
RC  SERIAL  CLAIMS  QUEUE  REVIEW 
RB  BINDERY  QUEUE  REVIEW 
VA  VENDOR  ADD/EDIT 
VQ  VENDOR  RECORD  DEFINITION 
RA  ROUTING  ADD/EDIT/DELETE 

VR  VIEW  REPORTS  NEW  REPORTS: 

VPR  VENDOR  PERFORMANCE  REPORT 

CAR  CLAIM  ACTIVITY  REPORT 

BAR  BINDERY  ACTIVITY  REPORT 

SER  SERIALS  CHECK-IN  ACTIVITY  REPORT 

JI  JOB  INIT  NEW  JOBS: 

CLN  CLAIM  NOTICES 

BIN  BINDERY  NOTICES 

OBN  OVERDUE  BINDERY  NOTICES 

PCR  PRE-CLAIM  REPORT 

UCR  UNFILLED  CLAIMS  REPORT 

BCR  BINDERY  CANDIDATES  REPORT  (PULL  SLIPS) 

SHL  SERIALS  HOLDINGS  LIST 

VEL  VENDOR  LIST 

HOD  HOLDINGS  DEFINITION  DELETE 

BID  BINDERY  INSTRUCTIONS  DELETE 

CAS  NEW  COMMANDS  IN  CAS: 

N  SEARCH  FOR  A  SPECIFIC  NUMBERED  ISSUE 
D  SEARCH  FOR  A  SPECIFIC  DATED  ISSUE 
H  REQUEST  HOLDINGS  SCREEN 
M  REQUEST  MARC  RECORD  DISPLAY 
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SERIALS  FILE  STRUCTURES 


The  file  structures  developed  for  the  new  serials  contrbl 
system  reflect  the  usual  concerns  of  an  integrated  system: 
avoiding  duplication  of  data,  keeping  data  used  together 
together,  and  simplifying  processing  by  using  similar  structures. 
They  were  also  influenced  by  the  greatly  enhanced  capabilities  of 
the  proposed  system,  by  the  draft  "USMARC  Format  for  Holdings  and 
Locations",  and  by  the  file  structures  of  the  proposed  ILS 
Acquisitions  Subsystem. 


HOLDINGS  FILE 


A  Key  to  many  of  the  tasks  is  getting  serial  holdings  in 
order.  Past  experience  has  shown  the  difficulty  of  sorting  dates 
and  V.I.P.S.,  elements  which  may  be  little  more  than  free  text. 

To  deal  with  this,  we  suggest  maintaining  a  new  hold 
file  in  forced  sequential  order,  supporting  it  with  entr; 
through  three  familiar  index  files;  chronology  (date),  enumeration 
(vol. , iss. , etc. ) ,  and  internal  vips-copy. 

There  are  several  advantages  to  this  design: 

1. Simplified  look-up.  All  look-ups  will  be  searching  the  same 
file  using  different  approches.  That  is  all  searches  will  consist 
of  a  single  look-up  of  a  starting  point  followed  by  a  browse  in 
the  ordered  file. 

2. Simplified  browse.  All  browsing  (display  of  list)  will  be  in 
the  same  file,  and  always  in  Order.  The  indexes  will  be  used 
Only  for  entry  into  the  main  file. 

35. Simplified  maintenance.  Only  one  file  will  require  sequence  and 
that  will  be  forced.  Reorganization  can  be  accomplished  without 
changes  outside  the  holdings  file  since  the  internal  I.D.  is  not 
affected.  Indexes  can  be  resOrted  and  reconstructed  as  required 
to  reflect  a  new  order  or  to  adjust  to  the  limits  of  the  sorting 
device. 

4.  Ease  of  conversion.  No  conversion  of  the  serials  files  will  be 
easy  or  fully  automatic.  Any  approach  we  choose  will  require 
human  input  of  newly  required  support  data.  This  method,  at 
least,  will  require  no  major  change  in  the  internal  vips-cOpy. 
Automatically  converted  files  should  be  in  at  least  as  good  sort 
order  as  their  predecessors. 

5.  The  structure  of  the  main  file  itself  can  be  quite  simple, 
requiring  only  one  level  to  maintain  the  sbrt.  This  will 

make  browsing  quite  simple.  Browsing  in  the  index  files,  which 


will  now  have  be  of  variable  depth,  is  eliminated. 

6. Will  have  true  sequence.  This  is  critical  for  claiming, 
binding,  and  for  keeping  prediction  algorithms  simple  and  broadly 
effective. 

How  it  will  work: 

1 . Direct  entry  by  barcode.  Go  from  internal  vips-copy  index, 
which  points  to  the  main  file.  Display  the  item. 

2.  Chronological  (date)  entry.  Enter  a  date.  Go  to  date  index  for 
entry  point  for  main  file.  Go  to  main  file  and  display  browse.  If 
the  searcher  has  input  a  wrong  form  of  the  date  (it's  free  text, 
after  all),  he  is  immediately  presented  with  examples  of  the 
correct  form  for  this  serial. 

3- Enumeration  (volume)  entry.  This  is  quite  the  same  as  date, 
allowing  entry  of  a  volume,  immediate  browsing  in  the  main  file 
with  enumeration  oriented  display  highlighting  the  correct  date 
form. 

How  it  will  be  done: 

What  is  required  is  a  simple  sort  key  (see  the  "YY"  node  in 
the  holdings  file)  allowing  reasonable  insertion.  The  key  will 
provide  for  large  number  of  issues  and  large  insertion.  Resorting 
should  seldom,  if  ever  be  required;  however  the  file  can  be 
resorted  with  newly  distributed  keys  and  all  index  pointers 
adjusted. 

Other  new  elements  in  the  holdings  file: 

The  "U"  nbde  is  a  link  to  the  subscription  file.  The 
subscription  file  is  modeled  after  the  order  file  of  the  proposed 
Acquisitions  Subsystem  and  contains  such  data  as  the  number  of 
copies  on  the  subscription,  links  to  associated  vendor  file(s), 
and  specific  claiming  information. 

The  "V"  node  is  a  link  to  the  caption  and  pattern  files.  A 
limitation  of  the  ILS  serials  control  subsystem  was  its  restriction 
to  four  levels  of  enumeration  and  the  uniform  labelling  of  these 
"volume,  issue,  part,  supplement".  There  appears  to  be  little 
reason  to  limit  enumeration  to  four  levels  or  to  carry  more 
levels  than  required  to  described  the  item.  The  displayed  text  of 
the  captions  will  be  kept  in  a  separate  file,  corresponding  in 
number  of  levels  with  the  number  of  levels  of  enueration  required 
by  the  item.  Keeping  captions  in  their  own  file  will  avoid 
unnecessary  repetition  of  caption  text  in  each  bibliographic 
record . 

The  "W"  node  contains  the  earliest  and  latest  issues  checked 
in  for  each  format.  This  is  the  source  of  the  consolidated 


holdings  statement  in  CAS. 

Known  publication  patterns  are  necessary  for  predicting  the 
receipt  of  issues  for  claiming  and  for  identifying  binding  units. 
Like  captions,  publication  patterns  will  be  kept  in  a  separate 
file  and  shared  among  titles  having  identical  patterns. 

The  prediction  flag  ("*")  denotes  issues  predicted  but  not 
yet  received.  As  issues  are  predicted,  entries  will  be  made  in 
the  "X"  and  "Y"  fields.  When  the  first  copy  Of  an  issue  is 
checked  in,  the  prediction  flag  will  be  killed  and  entries  added 
to  the  "YY"  and  "Z"  files. 

The  combination  [sid,cd]  (claiming  date  and  subscription  id) 
is  a  pointer  to  the  expected  receipt  file.  Once  the  date  of 
expected  receipt  has  passed,  the  item  moves  to  the  claims  file 
and  the  date  pointer  can  be  deleted. 


AS(BID,MIIS)=. . .MARC  Bibliographic  Tag  data... (no  change) 

*s(bid,,,u")=[sid][sid]... 

*S(BID, "V" , , -EFFDATE)=[cap#; patt#][cap#; patt#] ...  for  formats 
*S(BID, ”W" )=[ CAPTION#] [CATPION#]  ...for  consolidated  holdings  formats 
AS(BID, "W", format)=[l st  enumum][last  en][lst  chron;last  chron] 

[ist  al  cnum][last  alt  enum][lst  alt  chr6n; 
last  alt  chron] 
fOrmat2)=. . . . 
format3)=. . . . 

*S(BID, "X" ,0)=[ last  chronology] 

AS(BID,"X",0, chron, key)=*0*  or  [sid , cd] .. .until  all  checked  in 

• 

, chron, key )=[ sid, cd][ sid, cd][*] 
where  *=predicted  chronology 
,l)=[last  alt  chron] 

,1,alt  chron, key )=*0* 

• 

,alt  chron, key )=[ sid , cd][sid ,cd][*] 
where  *=predicted 

'S(BID, ”Y",0)=[last  enumeration] 

AS(BID,"Y",0,enum,key)=*0*  or  [ sid, cd]. . .until  all  checked  in 

• 

,enum,key)=[sid, cd][sid ,cd][*] 
where  *=predicted 
,l)=[last  alt  enum] 

,1,alt  enum, key )=*0* 

• 

,alt  enum, key )=[ sid, cd][ sid, cd][*] 
where  *=predicted 

aS(BID,"YY")=[ first  keyjlast  key] [first; last] [first ; last] .. . 

"YY", key )=[ chron] [enum] [alt. chron] [alt. enum] 

[vips][caption] 

,key).. . 


aS(BID, "Z",vips)=[key][last  copy#] 

,vips,cp)=T copy# (opt) ][call#][L/G] 

[MatType] [Type ][cirCat][ barcode] [bnd] 
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Definitions:  MARC  tags  are  for  reference.  Goal  is  input 

(and  someday  output)  compatibility  with  proposed 
the  USMARC  Format  for  Holdings  and  Locations. 


alt  chrOn 
alt  enum 

bnd 

caption  # 
cd 


chron 


cp 


enum 


key 


Pattern  # 


sid 

vips 


Alternative  numbering  scheme,  chronology. 

(MARC  863m) — see  date  below. 

Up  to  two  levels  for  alternative  numbering  scheme, 
enumeration.  (MARC  863g-h) 

FORMAT:  ae;ae — where  ae's  represent  levels  6f 
alternative  enumeration. 

Binding  flag — binding  unit  control#. 

Index  #  to  the  Master  Captions  file. 

(Similar  to  MARC  85336  &  86336) 

Caption  file  holds  data  frOm  MARC  853a-m. 

Claiming  date  (YYMMDD).  Date  after  which  item  not 
received  ready  for  review  prior  to  production 
of  claim  notice.  Based  on  date  of  expected 
receipt  plus  a  vendor/item  specific  grace 
period.  (cd=expected  date+claim  interval) 

Internal  date — see  below.  (MARC  863i-l) 

ANSI:  The  different  types  of  dates  used  by 
the  publisher  of  a  work  to  identify  th 
individual  bibliographic  units  of  a 
serial  (for  example,  date  Of  coverage, 
date  of  publication,  date  Of  printing,  Or 
date  of  reprinting. ) 

Internal  Copy  Code  (no  change,  however  the 
code  will  be  in  fixed  sequence,  so  the  code 
will  be  a  direct  internal  representation 
of  the  external  copy#). 

Up  to  six  levels  of  enumeration.  (MARC  863a-f) 
FORMAT:  el ;e2;e3*e4;e5;e6 —  where  e's  represent 
levels  of  enumeration  in  semicolon  pieces. 

ANSI:  The  nonchronOlogical  scheme  used  by 
the  publisher  on  the  bibliogrpahic  unit 
to  identify  the  individual  bibliographic 
units  of  a  serial  and  to  show  the 
relationship  of  a  bibliographic  unit  t6 
the  serial  as  a  whole. 

Internal  key  to  allow  proper  display  order. 

Key  will  have  to  provide  for  insertion  and 
will  probably  require  periodic  resOrting.  We 
have  in  mind  a  three  character  basic  key, 
derived  from  the  fOrty-three  (Or  perhaps 
sixty-three)  character  internal  code  string.  A 
possible  two  character  extension  will  allow 
for  extensive  insertion  before  resorting  is 
ever  necessary. 

Index  #  to  the  Master  Publisher's  Pattern 
file.  (Similar  to  MARC  85336  4  86336) 

Publication  pattern  data  is  in  MARC  853u-y. 
Subscription  id  (ref  to  subscription  data,  *SU) 
Internal  Enumeration  Code  (no  change). 


Internal  format  date:  yyyyammdd 


yyyy 

four  digit  year 

s 

one  character  binary  encoded 
season  or  range  of  seasons 

mm 

two  character  binary  encoded 
month(s)  or  range  of  months  or 

both 

dd(-dd) 

two  digit  day  Or  range  of  days 

where: 

1 “spring 
2“summer 
4-fall 
8=winter 

1 “January 
2=February 
4“March 
8“April 
1 6“May 
32=June 
64=July 
1 28=August 
256=September 
51 2*0ctober 
1024“November 
2048=December 


SUBSCRIPTION  FILE 


The  subscription  file  contains  information  specific  to 
individual  subscriptions.  It  is  linked  to  a  vendor  by  the  vendor 
ID  (VE)  and  possibly  to  another  vendor  for  fulfillment.  The 
bibliographic  record  is  linked  to  the  subscription  file  by  the 
"U"  node.  The  subscription  file  is  patterned,  for  convenience  and 
compatibility,  after  the  order  file  of  the  proposed  Acquisitions 
Subsystem  (AQO). 

‘SU ('”')* last  sid# 

*SU(sid, 1 )=[bidi  _format][ ][oid-link  to  order  file] 

,2)*[ ][J[first  claim  interval; subsequent  claims 
interval ] [ ] [ beginning  date ] [ ending 
date][auto-renewal  flag] 

,3)=. reserve  or  routing  queue] 

,4)= >VE][][][][number  of  copies] 

,6)=[number  of  claims  t6  send] 

,9)='number  of  lines  in  special  instructions 
,9,l)®first  line  of  special  instructibns 
,2)=*second  line  of  special  instructions 
• 

,9,n)=nth  line 

oid  Order  id — link  to  order  file 
VE  Vendor  id — link  to  vendor  file 
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CAPTIONS 


The  captions  file  contains  the  textual  labels  assigned  to 
each  level  of  specified  enumeration. 

*SC("  ")=last  used  cap# 

*SC("  ", {El ;E2;E3;E4;E5;E6} , {AE1 ;AE2) )=cap# 

*SC(cap#)=[E1 ;E2;E3;E4;E5;E6][AE1 ;AE2;AE3;AE4] 


Where  E's  represent  up  to  six  levels  Of  enumeration  and  AE's  up 
to  two  levels  of  alternative  enumeration.  The  caption  file 
contains  information  compatible  with  proposed  MARC  853a-h.  Each 
field  here  must  pair  with  a  field  in  the  holdings  enumeration 
record.  Levels  need  not  be  specified  if  not  used. 

For  example: 

*SC("  Mvol.jno 
*SC("#")=[vol. ;nO. ] 

shows  the  common  vOlume-number  pattern.  (Parentheses  indicate 
that  the  caption  is  not  displayed  (per  MARC) — and  perhaps  not 
needed. ) 

The  caption  number  is  similar  to  the  $6  linking  field  of  the 
MARC  853  and  863  tags.  It  differs  here  in  that  the  link  is  to  a 
caption  file  shared  by  multiple  holdings  records. 

The  caption  file  would  probably  be  supplied  with  many  of  the 
more  common  captions.  However,  additional  captions  would  be 
generated  "on  the  fly"  as  new  variations  are  created  in  Holdings 
Add/Edit. 

When  captions  for  a  new  item  are  processed  by  the  background 
filer,  the  file  of  existing  captions  will  be  checked  to  see  if  an 
appropriate  set  already  exists.  If  it  does,  the  associated 
caption  number  will  be  assigned  to  the  holdings.  If  a  new  pattern 
is  detected  (not  found  in  the  the  *'SC("  ")  file),  a  new  caption 
entry  will  be  created. 


PUBLICATION  PATTERNS 


Publication  pattern  files  contain  information  supplied 
during  Holdings  ADD/EDIT.  The  information  is  used  to  predict  the 
enumeration/ chronology  for  the  next  expected  issue.  The  proposed 
"USMARC  Format  for  Holdings  and  Locations"  keeps  publication 
pattern  information  in  the  u-y  and  $3  subfields  Of  the  853  tag, 
linking  it  to  each  holdings  record  (tag  863)  by  the  $6  subfield. 
Our  plan  is  to  keep  publication  pattern  information  in  a  shared 
file  in  order  to  avoid  duplication.  We  will  use  the  prescribed 
MARC  c6des  as  far  as  practical,  adapting  them  where  necessary, 
the  actual  procedures  used. 

*PATT=last  pattern  number 
*PATT(patt#)=[u][v][w][x][y] 

u  —  Bibliographic  units  per  next  higher  level. 

Form:  N;N;N;N;N,  where  N's  represent  number  of 
units  contained  in  up  to  five  sublevels.  For  the 
highest  level  this  information  is  nOt  relevant. 

v  —  Restart/continuous  numbering  code. 

Form:  X;X;X;X;X;X,  shere  N's  indicate  whether  each 
of  up  to  six  levels  increment  continuously  ("c") 
or  restart  ("r")  at  the  completion  Of  the  unit. 

w  —  Frequency  of  the  item. 

Lower  case  alphabetic  codes  are  used  for  those 
frequencies  which  have  a  fundamental  periodicity. 
Numeric  characters  for  those  for  which  nO 
periodicity  exists. 

Frequency  cOdes:  (from  the  MARC  holdings  format) 
a  -  Annual 

b  -  Bimonthly  (every  two  weeks) 
c  -  Semiweekly 
d  -  Daily 

e  -  Biweekly  (every  two  weeks) 
f  -  Semiannual 

g  -  Biennial  (every  two  weeks) 
h  -  Triennial  (every  three  years) 
i  -  Three  times  a  week 
j  -  Three  times  a  month 
m  -  Monthly 
q  -  Quarterly 
s  -  Semimonthly 
t  -  Three  times  a  year 
w  -  Weekly 

x  -  Completely  irregular 


x  —  Calendar  change. 

Specifies  the  chronological  point  at  which  the 
enumeration  increments  or  changes.  Two  numeric 
characters  (01-12  or  spring-21,  summer-22, 
autumn-23,  winter-24)  are  used.  MMDD  is  used  if  it 
is  necessary  to  specify  the  day  Of  change.  If  more 
than  one  level  of  change  is  required,  both  dates 
appear,  delimited  by  commas. 

y  —  Regularity. 

Specifies  any  irregularity  in  the  publication 
pattern.  Initial  ‘o'  or  'p'  indicates  whether 
omission  or  publication  is  being  noted.  The  MARC 
format  provides  a  system  Of  numeric  and  alphabetic 
codes  for  days,  weeks,  months,  and  seasons. 


PREDICTION  ALGORITHMS 


In  order  to  simplify  check-in  and  to  enable  automatic 
monitoring  of  serial  receipt  for  timely  claiming,  the  system  must 
be  able  to  predict  the  enumeratiOn/chronolbgy  designation  of  the 
next  expected  issue.  This  will  require  users  to  enter 
sufficiently  detailed  descriptions  of  serial  publication  patterns 
through  Holdings  Add/Edit.  (See  previous  sections.)  Prediction 
will  consist  of  incrementing  each  level  of  enumeration  and  the 
chronology  through  the  ranges  defined  by  the  publication  pattern. 
If  a  usable,  regular  pattern  cannot  be  identified,  a  prediction 
cannot  be  made;  and  each  issue  will  have  tO  be  entered  upon 
receipt.  For  serials  which  defy  automatic  prediction,  it  may  be 
useful,  to  assure  timely  claiming,  to  allow  user-input  Or  manual 
prediction. 


CLAIMS  FILES 


The  files  for  claims  control  may  be  the  most  dynamic  in  the 
serials  control  subsystem.  While  orderly  follow-up  on  missing  issues 
is  pursued,  check-in,  possibly  including  these  issues,  continues. 

The  same  files  are  subject  to  automatic  and  manual  updating.  A 
continuous  coherent  record  must  be  maintainable  from  first 
notation  through  review,  approval,  production,  follow-ups, 
abandonment,  and  decision  on  replacement. 

To  accomplish  this,  a  master  claim  record  for  each 
bibliograhic  item-subscription  will  be  established  as  it  becbmes 
a  candidate  for  claiming.  The  master  record  will  contain  claim 
information  about  the  item,  its  claim  history,  and  pointers  to 
supporting  files  in  which  there  is  a  record  of  the  item. 

We  have  noted  three  sources  of  claim  identification. 

1 .  Missed  issues  —  if  the  system  nbtes  a  holdings  gap,  for 
example,  when  a  user  checks  in  an  issue  later  than  that 
expected. 

2.  Non- receipt  —  if  an  issue  has  not  been  received,  and  the 
claim  interval  has  lapsed. 

3.  Manual  input  —  direct  input  of  items  into  the  claiming 
process  must  be  provided  for  claim  candidates  not  noted  by  the 
automatic  devices  of  the  serials  control  subsystem. 

When  new  items  are  added  to  the  claim  file,  they  will  also  be 
added  to  a  vendor  index  and  a  dated  review  queue. 

Numbers  one  and  two  above  depend  on  the  prediction  devices 
of  the  serials  control  subsystem.  As  each  issue  is  predicted  it  is 
noted  in  the  bibliographic  record  and  in  the  claim  date  file.  As 
each  issue  copy  is  checked  in  the  number  expected  will  be 
decremented  until  all  expected  issues  have  been  received  and  the 
entry  deleted.  The  nightly  DOWN  housekeeping  function  will  check 
the  claim  date  file  for  any  expected  items  not  received, 
establish  any  overdue  items  in  the  master  claim  file  as  candidates  for 
claiming,  and  delete  them  from  the  queue  of  expected  items. 


Claim  date  file: 


*SD( claim  date, BJD_key , sid)=[#copies] 

Master  claim  recOrd: 

*SL(BID_key, sid) =[#copies][ status ][ rd][ batch  #] 

rd — review  date,  YYMMDD 

batch# — points  to  vendor  claim  batch 

Master  claim  record,  history  node: 

*SL(BID_key,sid,"C")=[date  1st  claim][date  2nd  claim] ... [date  nth  claim] 
Message  node: 

ASL(BID_key,sid, "M")=number  of  lines  in  message 

,l)=first  line  of  notes  to  accompany 
claim. 

,n)=nth  line  of  notes  to  accompany 
claim. 

SUPPORT  FILES 
Vendor  index: 

*SL( "V" ,VE,BID_key, s id) 

Review  queue: 

*SL ( "R " , rd , BID_key , sid ) 

As  each  new  claim  candidate  enters  the  queue,  it  is  placed  also 
in  this  file  for  review.  If  approved,  its  status  is  changed 
accordingly,  it  is  deleted  from  the  review  queue,  and  added  to  a 
batch  ("B")  ready  for  production  (note:  for  single  item  reports  the 
batch  length  would  be  set  to  one).  Another  option  is  to  postpone 
review  to  a  later  date.  In  this  case,  the  review  entry  wbuld  be 
replaced  by  a  later  one  and  pointers  adjusted  accordingly. 

It  may  be  desirable  to  "batch"  claims  so  that  several 
items  are  reported  on  one  notice. 

*SL("B",VE)“last  batch# 

*SL( "B" ,VE, batch#)3[#  in  batch][status][date  printed] 

*SL("B",VE, batch#, BID_key, sid) 

It  may  also  be  necessary  to  have  a  queue  6f  batches  completed 
and  ready  for  approval  and/or  production  of  notices. 

*SL("C",VE, batch#) 
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CLAIM  STATISTICS 


Similar  claim  statistics  are  required  for  the  system  and  for 
each  vendor.  What  we  present  here  is  a  rec6rd  for  claim  activity 
in  atomized  form.  That  is,  only  files  for  daily  record  keeping 
are  shown.  From  these  daily  figures,  the  system  can  generate 
summaries  by  summation  for  whatever  periods  are  desired  On  a 
systematic  or  demand  basis.  Further  specification  of  report 
requirements  may  suggest  some  cumulation  of  the  raw  data. 

Two  types  of  data  are  required  for  the  statistical  reports: 
a  record  of  today's  activity,  and  an  updating  of  earlier  activity 
to  determine  performance.  The  update  is  required  in  order  to 
determine  such  things  as  the  fill  rate  for  items  claimed  earlier. 
Statistics  such  as  "claim  fill  rate"  and  "average  time  from  claim 
date  to  receipt  date"  require  calculation  rather  than  the  simple 
counting  of  other  ILS  statistics. 


System  level  statistics: 

*SL( "ST" ,YYMMDD)=[#claims][#filledl[#follow-ups][#declared  missing 
[#filled-R][#f6llow-ups-R][#decl.missing-R][days  to  fill-R 

Vendor  statistics  will  probably  be  kept  in  the  vendor 
parameter/status  file: 

“PV1 ( VE, 8, YYMMDD)=[#claims][#filled][#follow-ups][#decl. missing] 
[#filled-R][#follow-ups-R][#decl.missing-Rj[days  to  fill-R] 

where  the  R's  indicate  retrospective  or  fOllow-up  figures  for 
claims  placed  on  this  date.  The  first  line  of  pieces  records 
the  daily  activity.  This  is  an  addition  to  the  Vendor 
Parameter/Status  File  of  the  Acquisitions  Subsystem  (p.25.) 

An  alternative  structure  would  put  the  data  from  the  stacked 
pieces  in  separately  subscripted  nodes:  *SL("ST",YYMMDD,1 )=#claims, 
‘SL("ST",YYMMDD,2)=#filled,  etc. 

The  "Claiming  Activity  Report"  (  Requirements,  p.25) 
specifies  several  statistics  to  be  reported.  The  numbers 
following  refer  to  stacked  pieces  in  the  system  level  statistics 
and  may  represent  summation  Over  library  specified  periods. 

Number  Of  claims  placed:  1 

Number  of  claims  filled:  2 

Number  of  subsequent  claims  placed:  3  or  6 

Claim  fill  rate:  1/5*100 

Average  time  frdm  claim  date  to  receipt  date:  8/2 
Number  Of  items  declared  missing:  7 
Percentage  of  unfilled  claims:  1-5/1*100 


The  "Vendor  Performance  Report"  (  Requirements,  p.25) 
specifies  several  statistics  to  be  reported.  The  numbers  below 
refer  to  stacked  pieces  in  the  vendor  statistics  and  may 
represent  summation  over  library  specified  periods. 

Number  of  claims  sent:  1 
Percentage  of  claims  filled:  5/1*100 

Average  turnaround  time  betwen  claim  date  and  receipt  date:  8/2 
Number  of  subsequent  claims  sent:  3  or  6 
Percentage  6f  unfilled  claims:  1-5/1*100 

Additional  running  totals  can  easily  be  maintained  for  months 
(YYMM)  and  years  (YY). 


BINDING  FILES 


Binding  requires  several  system  parameters  as  well  as  the 
definition  of  local  binding  instructions.  To  do  this  will  require 
maintaining  a  master  binding  record  for  each  item  supported  by 
whatever  indexes  are  necessary. 

MASTER  BINDING  FILE 

The  master  binding  file  will  be  composed  of  system  default 
information,  information  for  the  binding  of  each  item,  and  the 
compiled  binding  units  along  with  any  information  specific  to  the 
unit.  There  are  several  questions  required  by  the  binding  system. 

These  are  followed  by  site-defined  question  responses. 

At  the  top,  the  system  default  responses  to  the  master  question 
list. 

aSB("  ",  1 )=Bindery  ID  (VE) 

*SB("  ",2)=Bindery  category 
,3)=Number  of  copies 

,4)=Number  of  issues  received  per  bindery  unit 
,5)=Enumeration  level  completed  per  binding  unit 
,6)=Number  of  days  after  last  issue  rec'd  before  binding 
, 7)=Special  instructions  to  bindery 
,8)=0verdue  interval 
,9)=<first  optional  question> 


NOTE:  VE  here  is  the  ID  of  the  bindery, 
a  pOinter  to  the  vendor  file. 

Then,  the  master  record  for  each  binding  item,  input  by  bindery 
add/edit  (based  upon  system  defaults). 

ASB(BID )=[ last  control#] 
aSB(BID,"  " , 1 )=Bindery  ID  (VE) 
aSB(BID,"  ",2)=Bindery  category 
,'5)=Number  Of  copies 

,4)=Number  of  issues  received  per  bindery  unit 
, 5)=Enumeration  level  completed  per  binding  unit 
,6)=Number  of  days  after  last  issue  rec’d  before  binding 
,7)=Special  instructions  to  bindery 
,8)=0verdue  interval 
,9)=<first  optional  questlon> 


Finally,  a  record  for  each  binding  unit,  based  on  the  item  master 
record,  but  containing  any  unit  specific  data  and  exceptional 
information.  Items  (not  pieces)  forming  a  binding  unit  are 
selected  by  the  system,  based  on  data  in  the  master  record  (items 
3  &  4  above).  Binding  "pull"  notices  may  be  generated  to  assist 
staff  with  retrieval  of  the  pieces.  When  a  copy  to  be  bound  is 
wanded,  the  system  will  replace  the  item-level  ID  with  the 
specific  copy-level  ID  and  flag  its  entry  in  the  holdings  file 
(control  number  in  the  "Z"  node)  to  indicate  inclusion  in  a 
binding  unit.  When  a  bound  volume  is  checked  in  from  the  bindery, 
all  of  the  indivdual  pieces  will  be  deleted  from  the  binding 
records  and  the  system.  A  new  item  record  for  the  bound  volume 
will  then  be  created.  The  status  of  the  binding  unit  will  also 
reflect  this.  When  all  of  the  items  in  shipment  are  accounted 
for,  the  binding  record  may  be  deleted  or  archived. 

NOTE:  There  remains  some  indecision  as  to  whether  individual 
piece  records  should  be  deleted  before  they  are  sent  to  the 
bindery  or  only  after  the  bound  volume  has  been  returned  and 
verified.  The  latter  seems  the  more  conservative  approach; 
however,  local  practice  may  determine  what  is  done. 


“SB( BID, control# )=[ status ] [ enum] [ c^ron] [ shipment#] [ review  date 

[date  sent][date  due  back] ...  other  data 
")[=[date  1st  notice][2nd  notice]... 


‘SB(BID, control# 


IID) 


.  Note:  System  creates  record  with 

ID's  Of  BID_VIPS.  When  item 
.  retrieved,  these  are  replaced  with 

.  full  internal  ID's. 

• 

*SB(BID, control#, IID) 

ASB(BID, control#, N)=data  (where  N  is  question  for 

which  binding  unit  data  different  from  item  data) 


SUPPORT  FILES 

Binding  tasks  will  be  supported  by  additional  files  such  as  (but 
not  limited  to)  the  following: 

Vendor: 


SB("V",VE, BID, control#) 


‘Due-back’  date: 


When  a  binding  unit  is  approved  for  shipment,  its  expected  date 
of  return  can  be  calculated  based  on  a  vendor  parameter  (or 
system  default).  This  also  must  be  editable  for  an  individual 
item  in  case  any  unusual  handling  is  required.  The  system  may 
also  have  to  deal  with  priorities  (high  and  normal?). 

*SB( "D",YYMMDD, BID, control# )=[ date  1st  notice][etc. ] 

New  or  ready  for  review: 

When  a  binding  unit  is  completed  and  added  to  the  master  binding 
file,  a  dated  entry  must  be  made  for  periodic  review.  In  case 
unit  is  not  ready  for  binding  (pieces  missing?),  review  could  be 
postponed  to  a  later  date. 

ASB("R”,YYMMDD, BID, control#) 


Shipment: 

It  may  be  necessary  to  keep  track  Of  bindery  shipments. 

*SB ( <SHIPMENT#> , BID , CONTROL#) 

Other  files  may  be  needed,  for  instance  binding  units  by  status 
for  review. 

BINDING  STATISTICS 

Similar  binding  statisti's  are  required  for  the  system  and  for 
each  bindery.  What  we  present  here  is  a  record  of  binding  activity 
in  atomized  form.  That  is,  only  files  for  daily  record  keeping 
are  shown.  From  these  daily  figures,  the  system  can  generate 
summaries  by  summation  for  whatever  periods  are  desired  on  a 
systematic  or  demand  basis.  Further  specification  of  report 
requirements  may  suggest  some  cumulation  of  the  raw  data. 

Two  types  of  data  are  required  for  the  statistical  reports: 
a  record  6f  today's  activity,  and  an  updating  of  earlier  activity 
to  determine  performance.  The  update  is  required  in  order  to 
determine  such  things  as  the  average  turnaround  time  between  date 
sent  to  the  bindery  to  date  received  from  the  bindery. 


System  level  statistics: 

*SB("ST",YYMMDD)=[#sent][#retnd][#notices][#overdue][#declared  missing] 
[#retnd-R  J [#nOtices-R ] [#overdues-R ] [ turnaround  time-R ] 

Statistics  for  each  bindery  used  will  be  kept  in  the 
vendor  parameter/status  file: 
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APV1 (VE,8,YYYMM0D)=[#sent][#rtnd][#notices][#overdue][#declared  missing] 
[#retnd-R][#nOtices-R][#overdues-R][ turnaround  time-R] 

where  the  R's  indicate  retrospective  or  follow-up  figures  for 
items  sent  to  be  bound  on  this  date.  The  first  line  Of  pieces  records 
the  daily  activity.  This  is  an  addition  to  the  Vendor 
Parameter/Status  File  of  the  Acquisitions  Subsystem  (p.25.) 

The  "Bindery  Activity  Report"  (  Requirements,  p.33) 
specifies  several  statistics  to  be  reported.  The  numbers 
following  refer  to  stacked  pieces  in  the  system  level  statistics 
and  may  represent  summation  over  library  specified  periods. 

Number  of  titles  sent:  1 

Number  of  titles  returned  from  the  bindery:  2 
Number  of  tieles  Overdue  from  the  bindery:  3 
Average  turnaround  time:  8/2 

Other  statistics  and  reports,  similar  to  those  in  the  claiming 
module,  may  also  be  generated.  Additional  running  totals  can 
easily  be  maintained  for  months  (YYMM)  and  years  (YY). 


SERIALS  FILE  STRUCTURES 


Serials  Transaction  Lengths 


Version  3.0  of  the  ILS  contains  modifications  to  the  Serials 
Check  In  function  which  reduce  the  length  of  a  serials 
transaction.  These  changes  are  as  follows: 

1.  In  previous  versions  of  the  ILS,  the  Serials  Check  In 
function  set  up  a  scratch  file  which  contained  the  entire 
serial  record  from  *S(BID). 

When  the  user  had  finished  with  his  updates,  the  ILS  set  up  a 
lengthy  transaction  in  the  processor  file.  However,  this 
transaction  was  marked  as  "processed"  by  the  Serials  Check  In 
software  since  the  update  took  place  in  real  time.  The 
purpose  of  the  transaction  record  in  the  processor  file  was 
for  the  Backup  and  Restore  function. 

As  a  result  of  this  method  for  Serials  Check  In,  each 
transaction  passed  to  the  processor  file  contained  the  entire 
bibliographic  record.  This  proved  to  be  very  costly  in  time 
and  storage  space  for  the  system. 

2.  Version  3.0  insures  that  the  user's  job  will  be  the  only  job 
in  the  system  which  is  updating  the  VIPS  information. 

Also,  in  Version  3.0,  a  slash  command  in  the  Serials  Check  In 
function  is  acceptable  at  any  point.  Nothing  will  be  filed, 
and  the  system  will  return  to  the  top  of  the  function. 

The  main  file  will  not  be  affected  until  the  transaction  is 
passed. 

Only  the  information  needed  by  the  user  for  Serials  Check  In 
will  be  retrieved  from  *S(BID)  and  placed  into  the  scratch 
file. 

When  the  user  has  finished  with  his  updates,  only  the  updated 
data  from  the  scratch  file  will  be  passed  to  the  processor 
file. 

The  *S(BID)  record  will  be  opened  in  order  to  prevent  more 
than  one  user  at  a  time  from  modifying  the  information. 

Because  Item  Delete  is  not  done  in  real  time,  as  Serials 
Check  In  is,  the  system  sets  a  flag,  *Xt,  to  prevent  Serials 
Check  In  use  of  the  record  until  the  delete  transaction  is 
complete.  This  flag  helps  to  prevent  a  conflict  between 
foreground  and  background  updates  to  the  same  record. 
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SERIALS  SCREEN  DISPLAYS 


Screen  displays  for  implementation  of  the  serials  system  pose  a 
somewhat  complex  problem,  due  to  the  necessity  of  displaying  and 
accepting  large  amounts  of  related  data  within  screen  displays 
designed  to  be  as  simple  and  understandable  as  possible.  To 
simplify  these  problems  and  at  the  same  time  allow  for  relatively 
easy  maintenance  and  future  expansion,  a  generic  screen  handler 
will  be  integrated  into  the  serials  system.  This  screen  handler 
will  be  used  for  most  serials  screens.  A  prototype  program  has 
been  developed  and  tested  for  this  purpose.  In  its  completed 
state,  the  screen  handler  will  fulfill  the  following 
specifications: 

1.  Template  file.  A  template  for  each  screen  will  be  stored 
in  *H(70)  containing,  in  stacked  pieces,  all  data  necessary  for 
data  handling  and  display:  prompts,  default  references,  storage 
variables,  format  check  algorithms,  etc.  Most  screens  will  use 
the  same  software. 

Data  will  be  designed  around  the  concept  of  the  data  element, 
with  all  input  specifications  grouped  together  for  each  data 
element  (which  from  the  user's  point  of  view  is  equivalent  to  a 
prompt).  The  control  global,  will  contain  in  one  location 
controlling  data  which  will  determine  the  operations  of  the 
screen  handler.  The  structure  of  the  control  global  is  as 
follows : 


*H(80, SCREEN  CODE)=screen  name*read  type“scroll/fix 
*H(80,SCR  CODE,  ITEM#,  "A" )~ 

"A" )= “prompt* row* column“default*mandatory*max  length 
*#  of  repeats*skip  to  pointer* skip  condition 

"B" )=format  check*format  2*variable  storage*protected 

field  code*error  message*list  global***“label  only 
“format  execute 

More  detailed  information  can  be  supplied  regarding  the  specific 
function  of  the  elements  in  the  control  globals  making 
up  the  templates,  if  necessary. 


2.  Standard  maintenance  procedure.  Each  screen  template  will 
be  created  using  a  screen  creation  utility,  making  maintenance 
far  more  simplified  and  standardized.  Screens  will  be  editable 
(regarding  prompts,  format,  variable  storage,  cursor  control, 
etc.)  via  the  same  screen  utility.  A  prototype  screen  creation/ 
editing  utility  has  be  developed  and  tested. 


3.  Defaulting.  Wherever  possible,  predicted  answers  will  be 


displayed  during  data  input  so  that  a  single  keystroke  can 
be  used  to  enter  the  data.  To  accommodate  the  space  constraints 
caused  by  displaying  large  amounts  of  date  in  a  simple  manner, 
the  default  response  will  appear  immediately  following  the 
prompt.  The  cursor  will  appear  superimposed  on  the  first 
character  of  the  default.  Three  responses  will  be  possible: 

A  'return'  will  move  the  cursor  to  the  next  prompt,  accepting 
the  data.  The  convention  '/D'  will  erase  the  default,  indicating 
that  no  data  should  be  entered  (for  optional  data).  If  the  user 
begins  typing  data,  the  default  will  be  erased  as  the  user 
inputs  the  new  data.  These  responses  are  illustrated  below: 

Example  1  Example  2 


LOCATION:  Periodicals  LOCATION:  Periodicals 

LOCATION:  /D  <erased>  LOCATION:  S  <erased> 

LOCATION:  LOCATION:  Stacks 

The  examples  are  displayed  on  separate  lines  for  clarity; 
in  actuality  action  would  take  place  in  the  same  line. 

4.  Validation.  All  input  will  be  validated  using  a  standardized 
validation  method,  using  a  variety  of  checks  (such  as  alpha¬ 
numeric  pattern  or  existence  on  a  list)  to  ensure  accuracy 

of  data  entry. 

5.  Windowing.  To  allow  for  the  simple  handling  of  large 
amounts  of  data,  a  pseudo-windowing  capability  will  be 
integrated  into  the  screen  handler.  Groups  of  prompts  can 
be  defined  as  belonging  to  a  specialized  subset  of  data 
elements.  A  portion  of  the  screen  (the  "window")  will 

be  repainted  as  needed  with  new  prompts.  This  could  be 
used  both  for  repeat  answers  and  for  groups  of  rarely  used 
questions,  which  would  Only  be  displayed  when  needed.  In 
this  way  user  friendliness  can  be  preserved  by  keeping 
prompting  simple  yet  allowing  for  complexities  when  they 
do  arise. 

Data  storage  for  windows  will  have  the  following  structure: 

*H( screen, item#, "W")=#  conditions/possible  subscreens 

1 )=condition*subscreen  codejprorapt  list  (optional)* 
column*1st  row*max  lines*max  cycle  repeats* 
prompt  location  code:  x-increraent,y-increment,  or 
prompt-defined  location* 

*H(screen,"W". subscreen  code)=total  data  prompts 

, item#, "A")=sarae  as  above 
, item#, "B")=same  as  above 

6.  Question  clustering.  A  scheme  in  which  prompts  can  be 
left  unnumbered  and  made  accessible  only  through  the  previous 


prompt.  This  technique  would  allow  forced  entry  of  related 
prompts  even  in  editing  mode. 

7.  Display  information.  The  screen  handler  will  allow  for  the 
display  of  headings  and  other  information  in  a  location- 
addressable  manner,  using  fixed  or  variable  data. 

8.  Data  input  control.  Two  types  of  data  reading  methods 

will  be  provided.  In  the  controlled  read  type,  the  screen  will 
not  allow  data  entry  beyond  or  before  the  allowed  space  for 
a  prompt.  This  will  not  allow  data  entry  to  overwrite  previous 
or  subsequent  prompts  and  data,  and  will  provide  an  obvious 
check  on  data  input  length.  This  input  type  will  use  a 
character  read  ('*'  read)  algorithm  to  build  data  entries. 
Because  reading  data  character-by-character  uses  more  CPU  time, 
a  switch  will  enable  the  changeover  to  an  unprotected  read 
for  situations  in  which  the  computer  is  under  heavy  load. 

9.  Control  of  data  entry  entry  path.  The  screen  handler  will 
allow  control  of  data  entry  by  use  of  mandatory  questions  and 
prompts  which  can  be  skipped  based  on  previous  answers. 

This  will  direct  the  user  through  the  correct  questions  (while 
avoiding  unnecessary  ones),  while  retaining  the  more  clear  and 
readable  screen-type  format. 
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HOLDINGS  ADD/EDIT 


A  mechanism  must  be  provided  to  allow  users  to  enter  new  serial 
records,  to  define  holdings  data,  acquisitions!  data,  parameters, 
claim  information,  and  bindery  instructions.  This  is  the  process 
whereby  a  user  defines  the  publication  pattern  and  control  data 
required  for  serials  modules  to  operate  properly. 

Data  entry  must  be  as  quick  and  easy  as  possible,  while  providing 
enough  flexibility  for  operators  to  precisely  define  each  title's 
pattern.  We  propose  a  standard  formatted  screen  which  prompts 
the  user  for  necessary  and  optional  data  for  each  title  holdings 
definition.  By  prompting  the  user  for  each  data  element,  the 
system  will  assist  operators  in  a  function  which,  after  initial 
retrospective  work,  will  not  be  used  regularly.  The  operator, 
then,  need  not  commit  to  memory  each  data  element  required  in  the 
the  system  (as  is  presently  the  case  in  using  some  ILS  functions 
such  as  Newly  Cataloged  Item. ) 

We  propose  the  following  screens  for  Holdings  Add/Edit  (to  define 
the  control  data  and  publication  pattern  of  each  individual 
serial  title). 


HOLDINGS  ADD/EDIT 

SCREEN  1 

ADD  MODE 

Edit  which  field? 

TITLE:  Bulletin  of  the  American  Society  for  Information  Science 
IMPRINT:  Washington,  DC:  ASIS 

ISSN:  0095-4403  CODEN:  BASICR 

OCLC:  00000000  CONTROL:  00000000 

1.  FORMAT:  Hardcopy 

10.  CLAIM  FORM:  Letter 

2.  STATUS:  Current 

11.  DAYS  BETW  CLAIMS:  30 

3.  TYPE  HOLDING:  Subscription 

12.  TERM/COPY:  Issue 

4.  RETENTION:  Bound 

13.  ISSUES/YEAR:  6 

5.  #  COPIES:  1 

14.  FREQUENCY:  Bimonthly 

6.  LOCATION:  Periodicals 

15.  CALENDAR  CHANGE:  01 

7.  VENDOR:  532 

16.  REGULARITY:  R 

8.  CLAIM  DAYS:  60 

17.  ANALYZE:  N 

9.  §  CLAIMS:  2 

18.  CAS:  Y 

19.  ROUTE:  N 

20.  COPY:  1  BARCODE:  Y  LAW  OR  GEN:  G  TYPE:  G  LOAN:  1 

21.  INSTRUCTIONS:  Route  copy  1  internally  before  shelving. 


HOLDINGS  ADD/EDIT 
ADD  MODE 


SCREEN  2 
File? 


TITLE:  Bulletin  of  the  American  Society  for  Information  Science 
IMPRINT:  Washington,  DC:  ASIS 

ISSN:  0095-4403  CODEN:  BASICR  OCLC:  00000000  CONTROL:  0000000 


FREQUENCY: 

Bimonthly 

LEVEL 

CAPTION 

DATE 

UNITS 

NUMBERING 

1 . 

1 

Volume 

Year 

1 

Continuous 

2. 

2 

Number 

Month 

6 

Restart 

3. 

3 

4. 

4 

5. 

5 

6. 

6 

7.  ALT  1 

8.  ALT  2 


9.  REGULARITY  NOTE: 


The  above  data  elements  translate  into  MARC  data  elements  as 
follows. 

ILS  DATA  ELEMENT  MARC  EQUIVALENT 
FROM  BIBLIOGRAPHIC  DATA: 


TITLE 

IMPRINT 

ISSN 

CODEN 

OCLC 

STATUS 

REGULARITY 

LOCAL  TO  ILS: 


245  Title  Statement 

260  Imprint 

022  ISSN 

030  Coden 

001  OCLC  Number 

008/06  Publication  Status  Code 

008/19  Regularity 


FORMAT 

Local  ILS  Dictionary] 

TYPE  HOLDING 

.Local  ILS  Dictionary] 

RETENTION 

Local  ILS  Dictionary] 

#  COPIES 

VENDOR 

[ILS  Vendor  File] 

CLAIM  DAYS 

.ILS  Parameter. 

#  CLAIMS 

.ILS  Parameter 

CLAIM  FORM 

ILS  Parameter 

DAYS  BETWN  CLAIMS 

.ILS  Parameter 

ANALYZE 

ILS  Parameter. 

CAS 

ILS  Parameter. 

ROUTE 

.ILS  Parameter. 

COPY 

BARCODE 

.ILS  Parameter] 

LAW  OR  GEN 

Local  ILS  Dictionary. 

TYPE 

.Local  ILS  Dictionary. 

LOAN 

Local  ILS  Dictionary. 

INSTRUCTIONS 

FROM  THE  MARC  HOLDINGS  RECORD: 


CONTROL 

LOCATION 

ISSUES/YEAR 

FREQUENCY 

CALENDAR  CHANGE 

CAPTION 

DATE 

UNITS 

NUMBERING 
REGULARITY  NOTE 
TERM/ COPY 


001  Control  Number 

852  Location/Call  Number 

853  Issues  Per  Year/Frequency 
853  Issues  Per  Year/Frequency 
853  Calendar  Change 

853  #a  -  fh  Term  Designating  nth  Level  of 
Enumeration 

853  -  ^n  Term  Designating  nth  Level  of 

Chronology 

853  Bibliographic  Units  per  Next  Higher 
Level 

853  fv  Restart/Continuous  Numbering  Code 
853  Regularity  Pattern 
853  /t  Term  Designating  Copy 


The  above  screens  would  be  called  up  after  cataloging  data  had 
been  entered  either  through  Newly  Cataloged  Item,  OCLC  Interface, 
or  Process  OCLC  Tape.  The  brief  bibliographic  citation  would  be 
supplied  from  the  bibliographic  source,  and  the  remainder  of  the 
screen(s)  would  contain  all  data  and  default  values  necessary  to 
define  holdings  records.  Note  that  several  series  of  screens  may 
be  required  for  titles  held  in  multiple  physical  formats  (all 
data  elements  are  subordinate  to  the  serial  "format"). 

Screen  one  will  have  certain  data  elements  defaulted  from  system 
parameters,  including: 

Format  =  Hardcopy 

Status  =  Currently  received 

#  of  copies  =  1 

Claim  days  =  locally-supplied  system  or  vendor  parameter 

#  of  claims  =  locally-supplied  system  or  vendor  parameter 
Claim  form  *  locally-supplied  system  or  vendor  parameter 

Days  between  claims  =  locally-supplied  system  or  vendor  parameter 
Copy  data  (line  20)  =  locally-supplied  item  record  defaults 
Analyze  =  locally  -supplied  parameter  (usually  =  N) 

CAS  =  locally-supplied  parameter  (usually  =  Y,  display  in  CAS) 
Route  =  locally-supplied  parameter 

All  defaults  may  be  overridden  by  the  operator  by  keying  in 
a  new  value  in  the  field  where  the  default  is  displayed. 

Defaults  may  also  be  deleted  by  a  special  "delete"  function  (such 
as  *D  or  /D  as  presently  used  in  the  ILS  Bibliographic 
Subsystem) . 

Certain  data  elements  will  be  controlled  by  standard  dictionary 
lists.  The  initial  system  will  include  tables  of  values  which 
are  standard  to  AACR2  and/or  the  MARC  format  for  holdings,  and 
will  also  include  user-definable  dictionaries.  Examples  of 
nationally  standardized  lists  of  values  include: 

Status  =  MARC  Receipt/acquisition  status  code  (008) 

Retention  =  MARC  General  retention  code  (008) 

Frequency  =  MARC  Frequency  code  (853) 

Calendar  change  =  MARC  Calendar  change  code  (853) 

Caption  =  MARC  and  AACR2  list  of  enumeration  terminology 
Chronology  =  MARC  and  AACR2  list  of  chronology  terminology 
Numbering  =  MARC  Restart/continuous  numbering  code  (853) 
Regularity  note  =  MARC  Regularity  pattern  (853) 

(ILS  future  calculation  implementation) 

When  a  user  must  input  data  in  a  field  which  is  controlled  by  a 
dictionary  or  other  file,  the  user  will  be  able  to  search  the 
file  and  browse  brief  entry  information  in  a  window  at  the  bottom 
of  the  Holdings  Add/Edit  screen.  For  example,  assignment  of  a 
vendor  may  require  that  the  user  search  the  vendor  file  to 
identify  the  appropriate  vendor  and  its  record  number. 

Mechanisms  similar  to  those  used  throughout  the  ILS  for  Item 
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Look-up  will  be  used  for  searching,  displaying,  and  selecting 
entries  from  dictionaries  and  files. 

The  second  screen  is  used  for  publication  pattern  definitions. 

The  Serials  Control  Subsystem  will  have  several  dictionaries 
which  are  used  for  these  definitions,  including  a  captions 
and  a  publication  pattern  dictionary.  When  the  user  is  inputting 
a  new  record,  this  second  screen  of  data  will  be  defaulted,  based 
upon  the  frequency  entered  in  the  first  screen.  The  operator 
will  also  then  have  a  chance  to  examine  and  change  the 
title’s  publication  definition,  or  to  create  a  new  one 
which  will  be  added  to  the  publication  pattern  dictionary.  These 
data  will  be  standardized  and  controlled  as  much  as  possible  to 
assist  in  building  prediction  algorithms  and  holdings  display 
algorithms  for  a  large  percentage  of  titles.  Completely 
irregular  titles  will  be  defined  more  generally,  and  claim 
parameters  can  be  reset  for  proper  operation. 

Each  field  which  is  controlled  by  dictionary  loDk-up  will  be 
validated  upon  user  input.  If  the  operator  is  not  sure  of  the 
appropriate  values,  the  system  will  provide  brief  look-up 
capabilities.  If  the  user  inputs  a  question  mark  in  any  field, 
a  window  will  open  up  at  the  bottom  of  the  screen  and  the  user 
may  search  or  browse  the  dictionary  for  assistance. 

Fields  required  for  system  control  will  be  defaulted.  The  user 
will  not  be  allowed  to  blank  out  required  fields.  Required  data 
elements  will  include: 

Format 

Status 

#  of  copies 
Retention 
Claim  days 

#  of  claims 
Claim  form 

Days  between  claims 

Frequency 

Issues  per  year 

Note  that  parameters  may  be  set  to  0  if  appropriate  (#  of 
claims).  Irregular  titles  may  require  generous  time  intervals 
for  claim  parameters  for  the  system  to  work  properly. 

Screen  one  will  force  the  operator  to  examine  every  field,  since 
most  of  the  data  are  required.  The  cursor  will  be  positioned  at 
each  field  and  the  user  will  be  prompted  to  accept,  change,  or 
delete  the  defaulted  data.  A  <RETURN>  will  bring  the  user  to  the 
next  field  for  input.  Once  the  entire  screen  in  filled  in,  the 
user  will  have  the  chance  to  edit  any  field  by  requesting  its 
reference  number.  When  work  is  completed,  the  second  screen  will 
be  displayed. 
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The  second  screen  will  provide  defaulted  data  from  the  frequency 
code.  The  user  will  be  placed  at  data  element  #1  for  input.  If 
the  data  is  acceptable  and  no  further  work  is  required,  a 
<RETURN>  will  bring  the  cursor  to  data  element  #7  for  input  of 
an  alternative  numbering  scheme.  If  none  is  required,  another 
<RETURN>  will  bring  the  user  to  data  element  #9  for  notes 
on  irregularities.  Finally,  the  user  will  be  able  to  edit  any 
data  on  the  screen.  When  everything  is  completed,  the  record 
may  then  be  filed  (both  screens  are  filed  at  the  same  time). 
Control  data  will  take  effect  immediately  in  check-in,  claiming, 
and  binding. 

Holdings  records  may  also  be  edited  as  needed  (frequency  change, 
vendor  changes,  etc.).  The  operator  will  call  up  the  above 
record  and  edit  as  required.  Certain  fields  will  be  protected 
(for  example,  bibliographic  data  would  not  be  edited  here,  but 
through  the  OCLC  Interface  or  via  Edit  Item).  Edits  to  this 
record  will  become  effective  in  check-in  immediately  upon  filing 
and  processing. 

For  titles  which  are  regularly  bound  (on  the  first  screen,  the 
user  input  a  RETENTION  code  =  "Bound"  or  "Replaced  by 
microform"),  the  user  will  be  supplied  with  a  third  screen  which 
allows  the  definition  of  enumeration  and  chronology  data  for  the 
bound  volumes.  This  data  will  frequently  differ  from  the 
publication  pattern  of  the  regular  subscription.  No  defaults 
will  be  provided  on  this  screen,  allowing  users  to  create  a 
pattern  which  matches  their  site-specific  binding  policies.  This 
third  screen  need  not  be  completed  during  initial  holdings 
definition;  it  may  be  filled  in  any  subsequent  time  as  an  "edit" 
to  the  holdings  record.  See  also  the  section  of  this  document 
on  the  BINDING  MODULE  for  information  on  creating  bindery 
instruction  records  for  regularly  bound  titles. 
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CHECK-IN  PROCESS 


SEARCH  SERIAL  RECORD 

User  searches  serial  title  by  available  indexes,  including: 

Title  key 
Title 
Coden 
ISSN 

OCLC  number 
Call  number 
Corporate  author 
System  retrieves  a  list  of  hits. 

User  selects  the  proper  record. 

System  prompts  for  format  and  copy. 

User  accepts  defaults, 

Else  user  inputs  different  data. 

DISPLAY  HOLDINGS  SCREEN 

System  displays  holdings  record,  including: 

Title 

Format 

Location  (call  number) 

Total  number  of  copies 
Instructions 

Next  expected  issue  (default  check-in  data) 

Issues  not  received 
Outstanding  claimed  issues 
Issues  at  the  bindery 
Last  issue  received 

User  may  request  MARC  record  display  at  any  time  with  the  M  command. 
CHECK-IN 

If  the  issue  in  hand  =  the  next  expected  issue, 

If  enumeration  is  correct, 

User  checks-in  issue  by  one  keystroke  acceptance  code. 

Else  user  redefines  enumeration. 

System  verifies  enumeration. 

If  data  dbes  not  fit  publication  pattern, 

System  displays  error  message. 

User  enters  data  again  or  slashes  out. 

Else  system  accepts  data. 

User  checks-in  issue  with  acceptance  code. 

PROMPT  FOR  ITEM  DATA 

System  prompts  to  accept  item  defaults. 

User  accepts  item  data, 

Else  user  edits  item  data. 

If  issue  requires  barcode,  system  prompts  to  wand  or  print 
barcode  (parameterized). 

If  issue  has  routing  queue,  system  generates  routing  slip. 


ADDED  COPIES 

System  prompts  for  additional  copies. 

If  added  copies  exist,  system  prompts  for  copy  number 
(default  =  next  sequential  number). 

System  displays  item  data  on  each  copy. 

System  continues  at  PROMPT  ITEM  DATA. 

MISSING  ISSUE  RECEIPT 

Else  if  issue  in  hand  =  issue  not  received, 

User  moves  to  not  received  cblumn. 

User  browses  items  not  received  for  proper  record. 

User  checks-in  issue. 

System  continues  at  PROMPT  FOR  ITEM  DATA. 

CLAIMED  ISSUE  RECEIPT 

Else  if  issue  in  hand  =  claimed  issue, 

User  moves  to  claimed  issue  column. 

User  browses  claimed  items  until  locating  proper  record 
User  checks-in  claimed  issue. 

System  continues  at  PROMPT  FOR  ITEM  DATA. 

BOUND  ISSUE  RECEIPT 

Else  if  issue  in  hand  =  bound  receipt, 

User  moves  to  "At  bindery"  column. 

User  briwses  items  to  locate  proper  record. 

User  checks-in  bound  volume  with  barcode. 

System  continues  at  ADDED  COPIES. 

CLAIM  CANCELLATION 

Else  if  a  claimed  issue  is  no  longer  available, 

User  moves  to  claimed  issue  column. 

User  brOwses  claimed  items  until  locating  proper  record. 

User  cancels  claimed  issue. 

System  prompts  user  for  cancel  verification. 

System  continues  at  SYSTEM  VERIFICATION. 

SYSTEM  VERIFICATION 

System  updates  CAS  holdings  statement  if  issue  =  newest  receive  ? 
System  updates  item  statuses. 

System  updates  claims  queue  as  needed. 

System  updates  statistics. 

System  deletes  bindery  queue  record  as  needed. 

System  prints  barcodes  if  required. 


SERIAL  CHECK-IN 


TITLE:  Bulletin  of  the  American  Society  for  Information  Science 
FORMAT:  Hardcopy  LOCATION:  Periodicals  TOTAL  COPIES:  1 
VENDOR:  Faxon  FREQ:  Bimonthly 
INSTRUCTIONS:  Route  copy  1  internally  before  shelving. 


ENUMERATION  NEXT 

NOT 

CLAIMED 

AT 

LAST 

EXPECTED 

RECEIVED 

BINDERY 

RECEIVED 

VOLUME 

20 

20 

19 

17 

20 

NUMBER 

6 

5 

12 

4 

YEAR 

1984 

1984 

1983 

1981 

1984 

MONTH 

JUN 

MAY 

DEC 

APR 

ACTION 

COPY:  1 

BARCODE:  Y 

LAW  OR  GEN: 

G  TYPE:  G 

LOAN:  1 

/ 

ADDED  COPIES:  0/ 

SPECIAL  ISSUE: 

C=Check-in  R=Redefine  issue  N=Cancel  claim  B=Br6wse  queue  F=Forward  M=MARC 


The  above  screen  is  the  basic  check-in  screen  for  titles  with 
three  or  less  levels  of  enumeration.  For  four  or  more  levels, 
see  the  alternative  screen  below. 

To  access  the  check-in  record,  the  user  inputs  a  search  argument 
to  retrieve  the  title  needed.  Once  the  title  is  selected,  the 
system  will  prompt  for  the  following  default: 

FORMAT:  Hardcopy/ 

This  default  may  be  overridden  to  check-in  another  format 
(e.g.  microfilm,  etc.).  HOwever,  in  the  majority  of  cases,  the 
default  will  be  acceptable  to  check-in  the  subscription  cOpy  of 
the  journal  in  question. 

The  top  portion  of  the  check-in  screen  includes  informational 
data  which  cannot  be  changed  by  the  user.  These  data  include  the 
bibliographic  title,  format,  location,  total  number  of  copies,  the 
vendor  from  which  the  subscription  is  ordered,  journal  frequency,  and 
instructions  for  the  cOpy  requested.  This  information  should 
help  the  user  decide  if  s/he  has  retrieved  the  correct  recOrd. 

If  the  record  is  the  wrong  one,  the  user  may  or  /  Out  t6  start 
again.  A  MARC  record  may  be  displayed  at  any  point  by  inputting 
the  "M"  command. 
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The  cursor  will  be  positioned  in  the  "Action"  field  under  the 
"Next  Expected"  issue  column.  In  most  cases,  the  user  will 
simply  want  to  check-in  the  copy  in-hand,  which  will  be  the  next 
predicted  receipt.  A  single  keystroke  of  "C"  (=check-in  this 
issue)  affirms  that  the  predicted  issue  is  cOrrectly  enumerated 
and  received.  If  the  issue  is  incorrectly  enumerated,  the  user 
inputs  an  "R"  predefine  issue)  in  the  action  field.  The  cursor 
will  then  be  positioned  over  the  first  enumeration  field  to  allow 
the  operator  to  overwrite  and  redefine  the  numbering.  The  user 
will  be  forced  to  approve  or  edit  each  level  of  enumeration  in 
the  redefine  mode.  The  system  will  verify  that  the  new  data  input 
in  redefine  mode  has  nOt  been  previously  input,  and  that  the  data 
conforms  to  the  holdings  pattern  defined  for  that  journal. 

If,  while  verifying  this  newly  input  data,  the  program 
detects  a  gap  (e.g.,  the  issue  received  is  number  7  rather  than 
number  6),  the  system  will  generate  a  potential  claim  record 
for  the  issue  not  received.  Once  the  enumeration  is  accepted 
or  edited,  the  cursor  will  be  positioned  after  the  item  data 
(the  line  with  the  barcode,  circulation  category,  loan  period, 
and  location  data).  If  the  user  enters  a  RETURN,  the  defaulted 
information  (from  the  Holdings  records  for  this  title  and  format) 
will  be  accepted.  If,  however,  the  user  wishes  to  change  any 
portion  of  the  item  data,  s/he  enters  an  "R"  for  redefining 
the  data.  The  cursor  will  then  be  positioned  over  the  "Copy” 
prompt,  and  the  user  will  be  forced  to  accept  Or  edit  each 
field  on  the  line.  If  the  site  is  profiled  to  wand  barcodes, 
the  system  will  prompt  for  the  barcode  as  the  last  data 
element  in  the  i^em  data  line.  If  the  site  is  profiled  to 
print  a  barcode,  the  system  will  do  so  after  the  check-in 
procedure  is  completed.  Finally,  the  cursor  will  be  positioned 
at  the  "Added  cbpies"  prompt  to  check  in  additional  copies  of  the 
journal.  If  the  user  inputs  a  number  of  additional  copies,  the 
system  will  then  return  to  the  item  record  line  for  acceptance 
Or  editing  6f  the  item  data.  This  will  continue  until  all 
additional  copies  are  checked  in. 

If  there  are  no  additional  copies  to  check-in,  a  response  of 
RETURN  at  the  "Added  copies"  prompt  will  return  the  user  to 
search  mode  to  continue  checking  in  other  journal  titles. 


Of  course,  there  are  many  other  possible  actions  to  take  when 
checking  in  a  received  issue.  If  the  issue  in  hand  is  a  back 
issue,  the  user  will  want  to  check  not  received,  claimed,  and 
bindery  issues  before  checking- in  the  issue.  This  is  done  by 
moving  to  the  action  field  below  the  column  desired  (e.g. 
to  the  second  action  field  to  work  with  not  received  items. )  Then 
the  user  may  browse  the  list  of  issues  with  the  status  of  not 
received.  This  is  done  by  inputting  a  B  (=browse)  in  the  action 
field.  The  system  will  then  rewrite  the  data  on  the  screen 
under  the  not  received  heading  with  enumeration  data  for  each  issue 
identified  as  missing.  The  browsing  will  proceed  from  the  61dest 
to  the  most  recent  issue,  assuming  replacement  copies  would  come 
in  sequentially.  Each  time  the  system  displays  enumeration  data 
for  another  issue,  the  user  has  the  option  of  checking-in  the 
issue  (C  command),  cancelling  the  claim  on  an  issue  (N  command), 
or  continuing  to  browse  forward  in  the  queue.  At  any  time,  when 
the  user  inputs  "C",  the  cursor  will  drOp  to  the  item  data  for 
normal  check-in  procedures. 

Whenever  the  user  selects  "R"  to  redefine  the  enumeration  of  an 
issue,  the  cursor  will  drop  to  the  "Special  issue"  prompt  after 
the  enumeration  is  redefined.  This  gives  the  user  a  chance  to 
input  free-text  data  about  the  issue  in  hand  (e.g.  topical  issue, 
special  supplement,  etc.). 

If  an  issue  has  a  routing  queue  attached,  the  routing  slip  will 
be  generated  before  proceeding  with  added  copies  to  check-in. 

The  method  used  in  the  present  subsystem,  i.e.  screen  printing 
the  slip,  will  be  used  in  the  new  subsystem. 

If  a  title  is  defined  in  the  Holdings  record  as  a  serial  which 
should  be  analyzed,  the  system  will  display  a  warning  note  to 
the  user  at  the  bottom  of  the  screen,  indicating  that  the  issue 
should  be  sent  to  cataloging  for  analysis. 

Note  that  bound  issues  returning  from  the  bindery  may  be 
checked-in  on  the  same  screen.  The  same  basic  procedure  will  be 
used  to  check-in  b&und  issues,  except  that  the  user  will  wand  the 
barcode  of  a  volume  received  at  the  "Action"  prompt,  (if  a  site 
does  not  barcode  bound  volumes,  the  "C"  command  will  be  required.) 
The  user  will  then  proceed  through  the  added  copies  prompt  as 
described  above.  Once  a  bound  vblume  is  checked-in,  the  bindery 
queue  record  is  also  deleted  (see  BINDERY  MODULE  description 
below) . 

If  it  is  deemed  necessary,  the  system  may  also  have  a  "hidden" 
delete  function  (the  X  command)  to  delete  and  issue.  This  command 
would  be  used  primarily  with  the  missing  •  -sues  never  received. 

By  making  Delete  a  hidden  command,  it  will  not  be  readily 
apparent  to  the  check-in  operator  that  this  can  be  done.  The 
command  will  n6t  be  listed  in  the  command  line,  and  if  delete 
is,  indeed,  selected  as  an  operator,  the  system  will  verify 
that  the  user  really  wants  to  delete  an  issue  by  requesting  a 


SERIAL  CHECK-IN 


TITLE:  Journal  of  ambitious  enumeration  schemes 
FORMAT:  Hardcopy  LOCATION:  Periodicals  TOTAL  COPIES:  1 

VENDOR:  Double  Bind  Subscription  Services  FREQ:  Daily 

INSTRUCTIONS:  Make  sure  you  double-check  the  number  before  accepting! 


ENUMERATION 

NEXT 

NOT  REC 

CLAIMED 

BINDERY 

LAST  REC 

VOLUME 

5 

4 

5 

5 

SECTION 

2 

1 

2 

2 

PART 

1 

1 

1 

1 

NUMBER 

5 

1 

5 

5 

ISSUE 

16 

2 

9 

15 

PIECE 

A 

A 

A 

B 

YEAR 

1984 

1983 

1984 

1984 

MONTH 

MAY 

JAN 

MAY 

MAY 

DAY 

16 

02 

09 

15 

SERIAL  (ALT1) 

105 

•104 

105 

105 

NUMBER  (ALT2) 

1 37 

02 

130 

136 

ACTION 

_____ 

_____ 

_____ 

_ 

C=Check-in  R=Redefine  issue  N=Cancel  claim  B=Br6wse  queue  F*F6rward  M=MARC 


The  above  screen  is  an  alternative  format  for  serials  with  four 
or  more  levels  of  enumeration.  This  example  is  fbr  a  worst  case 
situation,  in  which  all  6  levels  of  enumeration,  all  levels  Of 
chronology,  and  both  levels  of  alternative  enumeration  are 
defined.  In  these  special  cases,  the  system  will  not  display 
the  item  record  information  at  the  bOttbm  6f  the  screen.  That 
data  will  only  be  displayed  and  prompted  for  when  an  issue  is 
checked-in.  In  this  way,  enough  space  is  reserved  t6  display 
complete  enumeration  information.  The  system  will  otherwise 
behave  the  same  way  as  described  above. 
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ROUTING  FUNCTION  FILE  STRUCTURES 


In  the  existing  version  of  ILS,  routing  list  information  is 
kept  in  the  patron  file  and  in  the  master  bibliographic  file. 

The  present  structuring  of  this  data  is  inefficient  and  prevents 
editing  of  the  names  on  each  list.  Online  propbses  to  take  the 
references  to  the  routing  list  information  out  of  the  patron 
and  MBF  files  and  place  them  into  current  status  indexes. 

Global  F  contains  all  status  indexes  for  items.  A  new 
subscript,  "20",  will  be  created  for  this  file  t6  hold  routing 
list  information  as  follows: 

*F(20, BID. COPY)  =  One  line  of  user-entered  free  text  for 

the  permanent  routing  list  for  this  copy 

“F(20, BID. COPY, "")  -  Maximum  number  of  names  to  be  put  on 

each  page  of  the  routing  slip. 

“F(20, BID. COPY, 0)  =  Last  used  priority  number.  Used  in 

calculating  the  proper  sequence  number 
for  the  next  name  to  be  added  to  the 
permanent  routing  list  for  this  copy. 

“F(20, BID. COPY, Priority  on  List  =  [Patron  ID  (PID)] 

“F(20, BID. COPY, "T")  *  One  line  of  user-entered  free  text  for 

the  temporary  routing  list  for  this 
copy. 

*F(20, BID. COPY, "")  ■  Maximum  number  of  names  to  be  put 

on  each  page  of  the  temporary 
routing  slip. 

*F(20, BID. COPY, "T" ,0)  =  Last  U3ed  priority  number.  Used  in 

calculating  the  proper  sequence 
number  for  the  next  name  to  be  added 
to  the  temporary  routing  list  for 
copy. 

*F(20, BID. COPY, "T", Priority  on  Temporary  List  =  [Patron  ID] 


Global  G  is  the  patron  status  file.  It  is  accessed  quite 
frequently  in  reports.  Online  proposes  to  add  a  new  subscript 
to  this  file,  "14",  to  store  routing  list  information  for  each 
patron  as  follows: 

*G(14, PID, BID. COPY) 

*G(14, PID, BID. COPY, "T") 


ROUTING  LIST  PROCESSES 


The  functionality  of  the  present  ILS  routing  list  function, 
Add  Routing,  will  be  retained  in  the  new  Serials  Control 
Subsystem  while  being  expanded  to  accommodate  new  data  structures 
and  editing  capabilities. 

The  user  will  be  able  to  create  temporary  and  permanent 
routing  lists  for  any  defined  serial  copy.  S/he  will  be  able  to 
add,  edit,  and  delete  names  from  the  list  at  any  time.  The 
routing  function  will  parallel  the  Reserve  function  in  this 
respect.  All  changes  to  a  routing  list  will  be  processed  through 
the  background  filer. 

The  new  file  structures  for  routing  information  will  allow 
ease  of  editing  and  will  be  a  key  factor  in  reducing  the  size  of 
the  patron  (*M)  and  the  master  bibliographic  (*S)  files. 

A  problem  which  was  reported  by  ILS  customers  in  the  past 
concerning  the  system's  failure  to  remove  a  patron’s  name  from 
all  routing  lists  after  the  patron  was  eliminated  from  the  system 
in  Patron  Delete  will  be  resolved  in  the  new  routing  function. 

The  library  staff  will  be  able  to  input  a  one  line  free  text 
message  for  each  routing  slip.  This  message  may  be  edited  at 
any  time.  Should  the  library  staff  discover  that  more  than  one 
line  is  needed,  a  maximum  number  of  lines  for  the  free  text 
message  should  be  determined  in  order  to  have  as  many  names  on 
the  first  screen  of  a  routing  list  as  possible.  Library  staff 
will  most  likely  use  the  free  text  for  local  instructions  for  the 
copy  being  routed. 


The  Patron  Status  function  of  ILS  will  continue  to  provide 
a  list  of  journal  titles  routed  to  each  patron.  The  new  file 
structure  could  also  accommodate  a  Job  Initiation  report  of 
routings,  sorted  either  by  patron  or  by  title,  in  the  future. 

As  with  the  present  ILS  SE  function,  routing  slips  will  be 
formatted  and  generated  on  a  screen  as  issues  are  checked-in. 
The  printing  of  the  slips  will  be  optional,  especially  when 
older  issues  are  being  checked  in  but  not  routed  for  current 
awareness.  The  routing  slips  will  be  preformatted  to  allow 
for  multiple  pages  per  issues  if  the  number  of  patrons  per 
slip  exceeds  a  library  staff-determined  number.  The  staff  may 
input  a  different  number  for  each  copy.  However,  this  prompt 
will  only  be  given  if  the  number  of  names  on  a  list  exceeds 
fifteen  in  order  to  reduce  keying  time  for  the  staff. 

Permanent  routing  slips  will  continue  to  function  as  they 
do  in  the  present  version  of  ILS.  The  staff  may  create  a 
temporary  routing  list  for  a  copy  to  be  used  as  a  "hold"  or 
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"override"  slip.  Thus,  if  an  issue  is  checked  in,  and  data 
exists  for  a  temporary  list  and  a  permanent  list,  the  system 
will  display  the  temporary  list.  As  soon  as  this  list  is 
displayed  to  the  user,  the  system  will  delete  the  temporary 
list  information  from  the  files,  and  the  permanent  list  will 
again  take  precedence. 
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CLAIMS  PROCESS 


From  a  user's  point  of  view,  the  following  procedure  should  be 
used  for  working  on  the  claims  queue. 


SEARCH  THE  QUEUE 

User  searches  queue  by  one  of  three  methods: 

Search  by  vendor  look-up. 

Search  by  item  look-up. 

Request  next  available  claim  in  the  queue. 

System  retrieves  a  list  of  hits. 

User  selects  appropriate  record. 

DISPLAY  RECORD 

System  displays  a  claim  record,  including: 

Vendor  name 
Vendor  Title  ID 
Customer  account  number 
Format 

Serial  title 

Issue  enumeration  and  chronology  (repeatable) 
Free  text  message  (repeatable) 


ACTION 

System  prompts  for  action: 

Approve  the  claim 

Add  an  issue  to  claim 

Delete  an  issue  from  claim  queue 

Edit  an  issue  to  claim 

Postpone  an  issue  claim 

Browse  the  claim  queue 

Quit  this  record 

APPROVE 

User  enters  "Approval"  command. 

System  prompts  for  vendor  nbtes. 

System  updates  statistics  and  generates  a  transaction. 

System  generates  a  print  j6b. 

System  updates  item  status  to  =  "Claimed". 

User  reviews  next  claim  in  queue 

Else  user  returns  to  ACTION  level. 


ADD  A  CLAIM 

User  enters  "Add  a  claim"  command. 

System  prompts  for  enumeration  and  chronology  by  publication 
pattern  definition. 

System  verifies  data. 

If  data  is  invalid, 

System  displays  error  message. 

User  is  prompted  to  re-enter  data. 

Else  system  accepts  data. 

User  returns  to  ACTION  level. 

DELETE 

User  enters  "Delete  item"  command. 

System  asks  for  confirmation. 

User  enters  Y 

System  updates  statistics  and  generates  a  transaction. 
Else  user  enters  N 
User  returns  to  ACTION  level. 

EDIT  CLAIM 

User  enters  "Edit"  command. 

For  each  level  of  enumeration  or  chronology, 

System  promts  for  acceptance  or  editing. 

User  inputs  new  data. 

System  verifies  new  data. 

If  edited  data  is  invalid, 

System  displays  errbr  message. 

User  is  prompted  for  new  data. 

Else  system  accepts  data. 

System  returns  to  next  level. 

Else  user  accepts  present  value. 

System  returns  to  next  level. 

User  returns  to  ACTION  level. 

POSTPONE 

User  enters  "Postpone  claim"  command. 

System  prompts,  "Number  of  days  to  postpone  claim:" 

User  enters  number  of  days  to  postpone  claim. 

System  generates  claim  date. 

System  updates  statistics  and  generates  a  transaction. 
System  updates  item  status. 

User  returns  to  ACTION  level. 

BROWSE  QUEUE 

User  enters  Browse  Queue  command  to  see  next  item  record. 

System  displays  next  issue  in  queue. 

User  returns  to  ACTION  level. 


User  enters  "Quit  this  record"  cbmmand. 

User  returns  to  "What  do  you  wish  to  do?"  prompt. 

User  enters  <Return>  to  ask  for  next  record  in  retrieval  set 
System  displays  next  record. 

User  enters  ACTION  level. 

Else  user  enters  a  search  argument  to  re-search  the  file. 

System  returns  to  SEARCH  THE  QUEUE  level. 

Else  user  enters  "Quit  the  claim  queue"  command. 

User  returns  to  subsystem  level. 


CLAIMS  QUEUE 


What  do  you  wish  to  do? 


TITLE:  Bulletin  of  the  American  Society  for  Information  Sciene 

IMPRINT:  Washington,  DC:  ASIS 


ISSN:  0095-4403 

CODEN: 

BASICR  OCLC: 

00000000 

FORMAT:  Hardcopy 

VENDOR:  FAXON 

[Title 

has  multiple 

vendors] 

ACCOUNT  #:  1234567890 

VENDOR  TITLE  ID: 

0000000000 

ENUMERATION 

FIRST 

SECOND 

FINAL 

NEVER 

CLAIM 

CLAIM 

CLAIM 

RECEIVED 

VOLUME 

20 

19 

NUMBER 

5 

12 

YEAR 

1984 

1983 

MONTH 

MAY 

DEC 

COPY 

1 

1 

DATE  CLAIMED 

05/18/84 

ACTION 

VENDOR  NOTE: 


C=Approve  claim  A=Add  X=Delete  E=Edit  P=Postpone  B=Browse  queue  F=Forward 


The  claims  queue  screen  will  look  and  behave  similar  to  the 
check-in  screen  defined  previously.  The  above  screen  will  be 
used  for  titles  with  three  or  less  levels  6f  enumeration.  For 
four  or  mbre  levels,  see  the  alternative  screen  below. 

To  access  the  claim  queue,  the  user  inputs  a  search  argument  to 
retrieve  the  recbrd  desired.  Look-up  may  be  done  either  by  title 
or  by  vendor,  by  a  mechanism  similar  to  that  presently  used  by 
the  ILS  for  item  look-up. 

The  top  portion  of  the  claim  record  cannot  be  changed  by  the 
user.  These  data  include  the  bibliographic  information,  format, 
vendor,  and  various  vendor  identification  numbers.  This 
information  helps  the  user  identify  the  title  and  subscription 
correctly.  If  the  record  is  nbt  the  one  desired,  the  user  may 
ask  to  re-search  the  queue  for  another  recbrd. 
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The  cursor  will  be  positioned  in  the  "Action"  field  under  the 
"First  Claim"  issue  column.  In  most  cases,  the  user  will  simply 
want  to  approve  this  issue  for  claiming.  A  single  keystroke  of 
"C"  (=approve  this  claim)  affirms  that  the  issue  is  correctly 
enumerated  and  indeed  not  received.  If  the  issue  is  incorrectly 
identified,  the  user  may  input  an  "E"  (=edit  the  issue 
information)  in  the  action  field.  The  cursor  will  then  be 
positioned  over  the  first  enumeration  field  to  allow  the  operator 
to  overwrite  and  redefine  the  issue.  The  user  will  be  forced  to 
edit  or  accept  each  level  of  enumeration  in  the  edit  mode.  Then, 
when  the  user  has  completed  the  issue  identification,  the  cursor 
will  return  to  the  "Action"  field,  at  which  time  the  user  may 
Approve  the  claim. 

Whenever  the  Operator  approves  a  claim,  the  cursor  will  drop  to 
the  VENDOR  NOTE  field  t6  allow  input  of  a  free-text  message  to 
the  vendor  about  that  particular  issue.  This  message  will  appear 
On  the  claim  notice  each  time  it  is  sent  out.  If  a  message 
already  appears,  the  user  will  be  able  to  overwrite  it  with 
another  message,  or  simply  accept  it  as-is. 

If  the  user  selects  the  action,  "Postpone,"  s/he  will  have  a 
chance  to  delay  Or  postpone  this  particular  claim  notice  for 
a  given  number  of  days.  The  system  will  position  the  cursor 
on  the  error  message  line  at  the  bottom  of  the  screen  and 

prompt  for:  NUMBER  OF  DAYS  TO  DELAY  CLAIM:  _ .  The  user  will 

input  the  number  of  days.  The  DATE  CLAIMED  will  then  reflect 
this  future  day  for  informational  purposes.  The  cursOr  will 
then  return  to  the  "Action"  prompt  to  continue. 

Once  the  "First  Claim"  issue  is  approved,  if  their  are  more 
first  claim  candidates  in  the  queue,  the  system  will  display  the 
enumeration  information  for  the  next  item  in  the  queue.  The  user 
will  then  repeat  the  process  described  above. 

If  there  are  no  more  items  in  the  First  Claims  queue,  the  system 
will  then  place  the  cursor  under  the  "Second  Claim"  column  and 
repeat  the  same  steps  as  above.  This  will  continue  for  each 
column  of  data,  unless  the  user  exits  the  record.  Note  that 
there  will  be  as  many  columns  fOr  subsequent  claims  as  will  fit 
on  the  screen.  If  the  user  needs  to  define  more  claims  than  will 
fit  on  this  screen,  a  second  screen  for  the  fourth,  fifth,  etc. 
claims  will  be  formatted  and  displayed. 

The  top  level  prompt,  "What  do  you  wish  t6  do?"  will  allow  the 
user  to  select  a  next  action  after  this  particular  record  is 
completed  or  exited.  The  user  may  view  the  next  record  in 
his/her  retrieval  set,  quit  the  claim  queue,  or  re-search  the 
claim  file. 


CLAIM  QUEUE 


What  do  you  wish  to  do? 


TITLE:  Journal  of  ambitious  enumeration  schemes 
IMPRINT:  New  York:  Convoluted  Publishers,  Inc. 

ISSN:  0000-0000  FORMAT:  Hardcopy  VENDOR  TITLE  ID:  0000000000 
VENDOR:  Convoluted  Publishers  ACCOUNT  #:  9876543210 


ENUMERATION 

FIRST 

VOLUME 

4 

SECTION 

1 

PART 

1 

NUMBER 

1 

ISSUE 

2 

PIECE 

A 

YEAR 

1983 

MONTH 

JAN 

DAY 

02 

SERIAL  (ALT1  ) 

104 

NUMBER  (ALT2) 

02 

COPY 

1 

DATE  CLAIMED 
ACTION 

05/20/84 

SECOND  FINAL  NOT  RECVD 

5 
2 
1 
5 
9 
A 

1984 

MAY 

09 

105 

130 

1 


C=Approve  claim  A=Add  X=Delete  E=Edit  P=Postpone  B=Browse  queue  F=Forward 


The  above  screen  is  an  alternative  fftrmat  for  serials  with  fbur 
or  more  levels  of  enumeration.  This  example  is  for  a  worst  case 
sitatuation,  in  which  all  6  levels  of  enumeration,  all  levels  of 
chronology,  and  both  levels  of  alternative  enumeration  are 
defined.  In  these  special  cases,  the  system  will  not  display  the 
Coden,  OCLC  number,  and  VENDOR  NOTE  prompt  when  the  screen  is 
first  displayed.  The  VENDOR  NOTE  will  be  prompted  for  at  the 
bottom  of  the  screen  whenever  an  issue  is  apprbved  fbr  claim. 

The  Coden  and  OCLC  number  will  not  be  displayed  to  save  space, 
but  will  be  printed  On  the  notices  if  required.  Otherwise,  the 
system  will  behave  as  described  above. 


OUTPUTS 


All  outputs  listed  below,  both  hardcopy  and  online  reports  and 
notices,  will  be  specifically  formatted  with  the  Pentagon 
librarians  during  the  implementation  cycle.  The  following 
list  enumerates  the  data  elements  required  for  each  output, 
but  does  not  detail  a  specific  format  for  reporting. 


VENDOR  PERFORMANCE  REPORT 

The  Vendor  Performance  Report  will  be  an  online  repbrt  which  can 
also  be  screen  printed  if  desired.  Users  will  be  able  to  select 
a  specific  vendor  or  all  active  vendors.  For  each  vendor,  the 
display  will  include: 

Number  of  current  subscriptions 
Number  of  claims  sent 
Percentage  of  claims  filled 

Average  turnaround  time  between  claim  date  and  receipt  date 
Number  of  subsequent  claims  sent 
Percentage  of  unfilled  claims 


CLAIMING  ACTIVITY 

This  will  be  an  Online  report,  suitable  for  screen  printing  as 
well.  The  user  will  define  a  specific  date  range  for  which  data 
should  be  reported.  Data  elements  displayed  will  include: 

Number  of  claims  placed 

Number  of  claims  filled 

Number  of  subsequent  claims  placed 

Claim  fill  rate 

Average  time  fr&m  claim  date  to  receipt  date 
Number  of  items  declared  missing 
Vendors  tt  whom  claims  were  issued 
Percentage  of  claims  per  vendor 
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Whenever  the  group  vendor  screens  are  redisplayed,  the 
vendors  will  be  listed  in  alphabetical  order  by  name.  To  delete 
a  group  vendor,  at  the  "VENDOR:  "  prompt,  the  user  will  simply 
enter  a  "D"  cfincatenated  with  the  index  number  which  is  to  the 
left  of  the  vendor’s  name. 

After  the  user  has  finished  entering  the  grbup  vend6r  data, 
the  system  will  return  t6  the  prompt,  "Db  you  wish  to  enter 
C)oupon  Data,  D)iscOunt  Data,  or  G)r6up  Vendor  Data?" 


CLAIM  NOTICE 


This  printed  notice  will  be  generated  for  a  vendor  and  will 
include  several  cities  and  issues  to  be  claimed  on  one  slip. 
The  notice  will  include: 

Vendor  name  and  address 
Library  name  and  address 
Date  sent  but 

For  each  title  on  the  notice,  the  slip  will  report: 

Issue  enumeration  and  date 
Number  of  claim 
Free  text  message 

If  a  vendor  is  parameterized  tb  accept  phone  claims  instead  of 
mailed  notices,  a  special  version  of  the  above  notice  will  be 
generated  with  the  following  data: 

Vendbr  name  and  phone  number 
Title  to  claim 

Issue  enumeration  and  date 
Number  6f  claim 
Free  text  message 


PRE-CLAIM  REPORT 

This  will  be  a  printed  report  for  items  not  received  which  should 
potentially  be  claimed.  It  is  Intended  tb  be  a  list  Of  items 
which  should  be  searched  on  the  shelves  prior  to  actual  claiming. 
The  user  may  request  sorting  of  this  repbrt  either  by  title  or 
call  number,  depending  upOn  the  shelf  arrangement  bn  site.  For 
each  title  listed,  the  following  data  is  reported: 

Issue  enumeration  and  date 


UNFILLED  CLAIMS  REPORT 

This  will  be  a  printed  repbrt  for  all  items  which  were  claimed 
but  which  were  never  received.  It  is  intended  tb  assist 
librarians  in  the  decision  tb  declare  certain  items  missing  Or 
tb  attempt  ordering  them  from  but-of-print  dealers.  The  list 
may  be  sorted  either  by  title  br  by  call  number.  For  each 
title  reported,  the  report  will  include: 

Issue  enumeration  and  date 
Number  of  times  claimed 
Vendor 
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BINDERY  INSTRUCTION  RECORDS 


For  titles  which  are  regularly  bound,  the  new  subsystem  will 
allow  users  to  create  Bindery  Instruction  Records  for  each 
title.  These  records  will  provide  the  information  needed  t6 
predict  binding  units,  to  track  issues  at  the  bindery,  and 
to  identify  processing  data  to  the  binder.  Some  fields  will 
be  required  for  control  purposes,  while  other  fields  will  be 
site-specific  for  local  processing  needs.  Because  the  nature 
of  the  contents  of  these  records  is  so  variable,  the  Patron 
Question  List  and  Patron  Registration  software  will  be  used  to 
define  and  to  maintain  records  fdr  the  bindery.  The  new 
generalized  screen  display  software  will  n6t  be  used  here  due 
to  the  extent  to  which  variable  data  may  be  required  in 
bindery  instruction  records. 

Any  serial  holding  recbrd  which  includes  a  Retention  Code  = 
"Bound"  (see  section  on  HOLDINGS  ADD/EDIT)  may  have  a  bindery 
instruction  record  created  for  it.  Note  that  the  Retention  Code 
must  be  properly  set  before  a  bindery  record  may  be  created. 

This  is  done  for  control  purposes. 

The  following  data  will  be  required  in  the  Bindery  Instruction 
Record: 

Bindery  ID 
Bindery  Category 
Number  of  copies 

Number  of  issues  received  per  bindery  unit 

Enumeration  level  completed  per  bindery  unit 

Number  of  days  after  last  issue  received  before  binding 

Special  instructions  to  bindery 

Overdue  interval 

The  system  will  also  supply  a  standard  list  of  questions  which 
are  Optional  to  the  records  but  which  are  frequently  used  for 
bindery  instructions.  These  optional  questions  shall  include 
the  following: 

Bind  title  page? 

Bind  table  of  contents? 

Bind  index  in  front,  in  back,  or  delete? 

Remove  ads? 

Remove  front  covers? 

Remove  back  covers? 

Color  of  binding 
Color  of  lettering 
Title  on  spine 
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The  system  will  also  allow  each  site  to  define  its  own  questions 
required  fbr  bindery  instructions.  The  mechanism  to  define  these 
questions  shall  be  the  same  as  is  presently  used  in  the  Patron 
Question  Definition  function  (PQ),  including  the  ability  to 
create  different  question  lists  for  different  categories  Of 
binderies.  This  capability  will  be  particularly  useful  for 
sites  which  wish  to  track  titles  which  are  replaced  by  microform 
in  lieu  of  binding.  A  special  Bindery  Category  equal  to 
"Microform"  will  be  created  to  allow  sites  to  define  bindery 
instruction  records  for  titles  which  they  wish  to  monitor  for 
ordering  on  microfilm  or  microfiche. 

Data  entry  for  Bindery  Instruction  Records  will  behave  the  same 
way  that  Patron  Registration  presently  does  (PR  functibn).  The 
user  will  search  for  a  serial  title  and,  if  the  title  does  not 
yet  have  bindery  data  created,  will  be  prompted  to  create  a 
Bindery  Instruction  Record.  If  the  title  already  has  bindery 
data  created,  the  record  will  be  displayed  and  the  user  will  have 
the  chance  to  edit  any  field  in  the  record.  Once  a  recbrd  has 
been  created,  the  control  data  for  predicting  the  next  bindery 
unit  will  become  effective. 

A  sample  bindery  record  may  appear  as  follows: 


BINDERY  ADD/EDIT 

TITLE:  Bulletin  of  the  American  Society  for  Information  Science 
BINDERY  ID:  10 
BINDERY  CATEGORY:  Bound 
NUMBER  OF  COPIES:  1 

NUMBER  OF  ISSUES  RECEIVED  PER  BINDERY  UNIT:  6 

ENUMERATION  LEVEL  COMPLETED  PER  BINDERY  UNIT:  Volume 

NUMBER  OF  DAYS  AFTER  LAST  ISSUE  RECEIVED  BEFORE  BINDING:  30 

OVERDUE  INTERVAL:  90 

BIND  TITLE  PAGE?  Y 

BIND  TABLE  OF  CONTENTS?  Y 

BIND  INDEX  IN  FRONT,  IN  BACK,  OR  DELETE?  F 

REMOVE  ADS?  N 

REMOVE  FRONT  COVERS?  Y 

REMOVE  BACK  COVERS?  Y 

COLOR  OF  BINDING:  5 

COLOR  OF  LETTERING:  1 

TITLE  ON  SPINE:  Bulletin,  ASIS 

SPECIAL  INSTRUCTIONS  TO  BINDERY: 


FILE?  Y 
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Once  a  Bindery  Instruction  Record  has  been  filed,  that  title  will 
be  automatically  tracked  by  the  Binding  module  and  will  be  placed 
in  the  bindery  queue  as  soon  as  the  first  bindery  unit  is 
identified. 
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TITLES  REPLACED  BY  MICROFORMS 


For  title  which  are  regularly  replaced  by  microfilm  or  microfiche 
editions,  a  bindery  instruction  record  should  also  be  created  to 
prompt  the  library  when  to  order  the  replacement  edition,  and 
when  to  replace  individual  item  records  with  microform  volume 
item  records.  Any  title  which  include  a  Retention  Code  equal 
to  "Retained  until  replaced  by  microform"  must  have  a  bindery 
instruction  record  created  for  it.  A  typical  bindery  record 
for  these  special  cases  must  have  the  Bindery  Category  set  to 
equal  "Microform."  A  sample  record,  which  will  necessarily  be 
brief  due  to  the  lack  of  page  binding  instructions,  may  look 
like  the  following: 


BINDERY  ADD/EDIT 

TITLE:  Library  Technology  Reports 
BINDERY  ID:  11 
BINDERY  CATEGORY:  Microform 
NUMBER  OF  COPIES:  1 

NUMBER  OF  ISSUES  RECEIVED  PER  BINDERY  UNIT:  12 
ENUMERATION  LEVEL  COMPLETED  PER  BINDERY  UNIT:  Volume 
NUMBER  OF  DAYS  AFTER  LAST  ISSUE  RECEIVED  BEFORE  BINDING:  365 
OVERDUE  INTERVAL:  90 

TYPE  MICROFORM:  16mm  negative  roll,  35X  reduction  ratiO 
SPECIAL  INSTRUCTIONS  TO  BINDERY: 


FILE?  Y 


Titles  which  are  due  to  be  brdered  on  microform  will  appear  in 
the  bindery  queue  for  review  along  with  regularly  bound  titles. 
Usually,  these  titles  will  be  ordered  frOm  a  different  source 
(i.e.  Bindery  ID)  and  will  be  retrievable  by  a  different  Bindery 
ID.  Bindery  ID's  are  actually  links  to  the  Vendor  file,  and 
will  be  searched  via  the  vendor  iOOk-up  software.  Microfbrm 
titles  will  be  handled  through  the  bindery  module  in  the  same 
manner  as  regularly  bound  titles,  except  for  the  fact  that  the 
instruction  records,  as  described  above,  may  be  different. 


ACCESSING  THE  BINDERY  QUEUE 


From  the  user's  po?nt  of  view,  the  following  procedure  will  be 
used  when  working  with  the  bindery  queue. 


SEARCH  THE  QUEUE 

User  searches  the  queue  by  One  of  three  methods: 

Search  by  title  look-up. 

Search  by  bindery  look-up. 

Request  next  available  title  in  the  queue. 

System  retrieves  a  list  of  hits. 

User  selects  appropriate  record. 

DISPLAY  RECORD 

System  displays  a  bindery  recbrd,  including; 

Bindery  name 
Bindery  category 
Shipment  number 
Free  text  message 
Customer  account  number 
Shipment  date 

Bindery  unit  enumeration  and  chronology 
Serial  title 

Issue  enumeration  and  chronolbgy  (repeatable) 

FUNCTIONAL  COMMAND 
System  prompts  for  action: 

Approve  the  entire  record 

Remove  a  title  from  the  bindery  queue 

Edit  a  bindery  record 

Add  an  item  to  a  record 

Postpone  a  title  fOr  the  bindery 

View  next  record  in  the  queue 

Re-search  the  queue 

Quit  the  queue 
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APPROVE 

User  enters  "Approval"  command. 

System  prompt  for  deletion  of  individual  item  records. 

User  deletes  item  record  with  "Y"  or  wanding  barcode. 

Else  user  skips  to  next  item  record. 

System  prompts  for  acceptance  6f  new  bindery  unit  item  recOrd. 
User  approves  item  recOrd. 

Else  U3er  edits  item  record  for  proper  enumeration. 

System  displays  subsequent  screens  of  user-defined  data. 

User  edits  data. 

Else  user  files  data. 

System  updates  statistics  and  generates  a  transaction. 

System  deletes  individual  item  records. 

System  sets  item  status  to  =  "At  Bindery." 

System  generates  print  job. 

User  returns  to  FUNCTIONAL  COMMAND  level. 

DELETE  TITLE  FROM  QUEUE 
User  enters  "Delete"  command. 

System  updates  statistics  and  generates  a  transaction. 

User  returns  to  FUNCTIONAL  COMMAND  level. 

EDIT  RECORD 

User  enters  "Edit"  command. 

System  prompts  "What  d6  you  want  to  edit?" 

If  user  enters  line  number  of  data  element  tt  edit, 

If  field  in  unprotected,  system  prompts  for  new  data. 
Else  system  displays  error  message. 

User  returns  to  "What  do  you  want  to  edit?" 

User  enters  new  data. 

System  verifies  new  data. 

If  edited  data  is  invalid. 

System  displays  error  message. 

User  is  prompted  for  new  data. 

Else  system  accepts  data. 

System  updates  transaction  log  and  statistics. 

User  returns  to  "What  do  you  want  to  edit?" 

Else  user  enters  <Return>. 

System  returns  to  FUNCTIONAL  COMMAND  level. 

ADD  AN  ITEM  TO  THE  NOTICE 

User  enters  "Add  an  item"  cbmmand. 

System  prompts  for  enumeration  and  chronology  data  following 
publication  pattern  definition. 

User  enters  data. 

System  verifies  data. 

If  data  is  invalid, 

System  displays  error  message. 

User  is  prompted  to  re-enter  data. 

Else  system  accepts  data. 

System  updates  transaction  log  and  statistics. 

System  updates  item  status. 


POSTPONE  TITLE  FOR  BINDERY 

User  enters  "Delay  binding"  command. 

System  prompts  for  "Postponement  interval:" 

User  enters  number  of  days  to  postpone  shipment  to  bindery. 
System  updates  statistics  and  generates  a  transaction. 

User  returns  to  FUNCTIONAL  COMMAND  level. 

VIEW  NEXT  RECORD 

User  hits  <Return>  to  ask  for  next  record. 

System  displays  next  record  in  retrieval  set  or  queue. 

User  returns  to  FUNCTIONAL  COMMAND  level  at  end  of  set. 

RE-SEARCH  FILE 

User  enters  a  search  argument  to  re-search  the  file. 

System  returns  to  SEARCH  level. 

QUIT 

User  enters  Q  to  exit  the  function  entirely. 

User  returns  to  subsystem  level. 


BINDERY  QUEUE 


SCREEN  1 

What  do  yt>u  wish  t6  do? 


TITLE:  Bulletin  of  the  American  Society  for  Information  Science 
BINDERY:  Capitol  Bindery  Group  CATEGORY:  Bound 
ACCOUNT  #:  1234567890  SHIPMENT  #:  1  SHIP  DATE: 


BINDERY  UNIT:  VOLUME  18  1982 


REF 

VOLUME 

NUMBER 

MONTH 

YEAR 

1  . 

18 

1 

JAN 

1982 

2. 

18 

2 

MAR 

1982 

3. 

18 

3 

MAY 

1982 

4. 

18 

4 

JUL 

1982 

5. 

18 

5 

SEP 

1982 

6. 

18 

6 

NOV 

1  982 

7.  SPECIAL  INSTRUCTIONS: 


DELETE  ITEM: 


DELETE 


V=Approve  X=Delete  E=Edit  A=Add  item  P=Postpone  B=Browse  queue  F=Forward 


When  a  user  retrieves  a  record  in  the  bindery  queue,  a  display 
similar  to  the  one  above  will  appear,  regardless  6f  whether 
access  was  gained  by  title  look-up,  bindery  lOok-up,  or  paging 
through  the  queue.  The  screen  supplies  brief  title  and  bindery 
identification  information  which  cannot  be  edited  here  (done 
via  Edit  Item  or  Bindery  Add/Edit).  Individual  issues  which  are 
ready  for  binding  are  identified  by  enumeration  and  chrOnblOgy 
(and  cOpy/locational  data  if  present  in  items)  so  a  screen  may  be 
printed  off  as  a  shelf  pull  slip.  If  special  instructions 
existed  for  the  binder,  they  would  also  appear;  otherwise,  they 
may  be  added  here. 


When  the  above  screen  in  retrieved,  the  cursor  will  be  positioned 
at  the  prompt,  "What  do  you  want  to  do?  The  choice  of  actions 
is  summarized  on  the  last  line  of  the  screen,  and  is  detailed  in 
the  structured  English  above. 

If  the  user  selects  "V"  for  an  action,  the  system  will  then 
prompt  for  deletion  of  each  individual  item.  The  cursor  will 
be  positioned  under  the  DELETE  ITEM  column  of  the  first  item, 
and  the  user  will  be  prompted  to  wand  in  the  barcode  of  the 
issue  being  shipped  to  the  bindery.  If  the  barcode  does  not 
match  the  copy  as  defined  on  the  screen,  the  user  will  be 
warned  of  the  inconsistency  and  re-prompted  for  the  barcode. 

(Note  that  a  user  may  edit  the  item  record  to  conform  to  the 
issue  in  hand,  usually  to  change  the  copy  number.)  Upon 
entry  of  the  first  item  barcode,  the  system  will  subsequently 
position  the  cursor  On  each  succeeding  item  line,  prompting 
for  the  barcode  of  each  issue  which  is  being  shipped  to  the 
bindery  and  which  should  have  its  own  copy  record  deleted. 

The  actual  item  deletions  will  nOt  Occur  until  the  entire 
function  is  completed.  (Note  that  for  sites  which  do  not  barcode 
items,  when  the  user  is  prompted  to  DELETE  ITEM,  s/he  must 
enter  a  "Y"  for  deletion  of  each  item  record.) 

At  any  time,  if  the  user  chooses  the  command  "E"  to  edit  any 
field,  the  prompt  will  change  to  "What  do  you  want  to  edit?"  The 
user  will  then  input  the  reference  number  Of  the  data  element 
which  needs  modification.  The  cursor  will  then  be  positioned 
over  that  data  element  for  overwriting  or  acceptance.  Note  that 
an  entire  line  may  not  be  editable. 

If  all  the  items  which  are  ready  for  the  bindery  cannot  fit  on 
the  above  screen,  the  message  (MORE)  will  appear  at  the  bflttOm 
and  the  user  may  brOwse  through  the  list  of  items  for  review. 
Additional  items  will  appear  in  a  window  in  the  middle  of  the 
screen,  retaining  the  data  at  the  top  and  bottom  6f  the  screen 
for  informational  purposes. 

If  the  user  wishes  to  remOve  the  title  from  the  bindery  queue 
entirely,  the  "X"  (Delete)  command  is  issued.  The  system  will 
remove  the  record  from  the  queue  and  flag  the  record  for 
completion  of  this  bindery  cycle. 

If  the  user  wishes  to  delay  shipment  of  this  title  (for  example, 
to  wait  for  receipt  of  issues  presently  unavailable)  to  the 
bindery,  s/he  should  choose  the  "Postp6ne"  option.  The  system 
will  then  prOmpt  the  user  to  input  NUMBER  OF  DAYS  TO  DELAY 

SHIPMENT:  _ .  The  SHIP  DATE  will  then  appear  in  the  record, 

calculated  from  today's  date; 
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BINDERY  QUEUE 


SCREEN  1 

What  do  you  wish  to  do? 


TITLE:  Bulletin  of  the  American  Society  for  Information  Science 

BINDERY:  Capitol  Bindery  Group  CATEGORY:  Bound 

ACCOUNT  #:  1234567890  SHIPMENT  #:  1  SHIP  DATE:  06/30/84 

BINDERY  UNIT:  VOLUME  18  1982 

REF  VOLUME  NUMBER  MONTH  YEAR  DELETE  ITEM: 


1.  18  1  JAN  1982 

2.  18  2  MAR  1982 

3.  18  3  MAY  1982 

4.  18  4  JUL  1982 

5.  18  5  SEP  1982 

6.  18  6  NOV  1982 

7.  SPECIAL  INSTRUCTIONS: 


V=Approve  D=Delete  E=Edit  A=Add  item  P=Postpone  B=Browse  queue  F=Forward 


A  bindery  shipment  notice  will  not  be  generated  for  this  title 
until  the  shipment  date  is  reached.  (Note  that  generation  of 
bindery  notices  is  done  via  the  usual  Jl  function.) 

Shipment  dates  will  appear  bn  bindery  records  Only  when  a  notice 
has  been  generated  (a  record  must  be  approved  before  being  placed 
in  the  notice  queue)  or  when  a  delay  date  is  defined.  Users  will 
know  that  a  record  has  not  yet  been  approved  if  a  SHIPMENT  DATE 
is  nOt  present. 

Once  the  user  Approves  the  record  (V)  and  has  deleted  all  item 
records  for  the  unit,  the  cursor  will  be  positioned  at  the 
BINDERY  UNIT  line.  The  user  must  accept  or  edit  the  new  item 
record  which  replaces  the  individually  deleted  item  records 
by  indicating  either  V  or  E: 

BINDERY  UNIT:  VOLUME  18  1982  V  or  E/ 

If  the  user  wishes  to  edit  the  data,  s/he  will  be  prompted  for 
each  defined  level  of  enumeration  and  chronOlfcgy.  Otherwise, 
once  the  unit  is  approved,  the  system  will  then  format  and 
provide  subsequent  screens  of  instructions  and  locally-created 
questions.  These  data  elements  may  be  edited  each  time 
a  unit  is  sent  to  the  binder.  A  sample  screen  is  provided  below. 
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BINDERY  QUEUE 


1.  BIND  TITLE  PAGE? 

2.  BIND  TABLE  OF  CONTENTS? 

3.  BIND  INDEX? 

4.  REMOVE  ADS? 

5.  REMOVE  FRONT  COVERS? 

6.  REMOVE  BACK  COVERS? 

7.  COLOR  OF  BINDING 

8.  COLOR  OF  LETTERING 

9.  TITLE  ON  SPINE 


SCREEN  2 

What  do  you  want,  to  edit? 

YES 

YES 

IN  FRONT 
NO 
YES 
YES 
5 
1 

Bulletin,  ASIS 


This  second  screen  lists  the  remaining  questions  present  in  the 
title's  bindery  instruction  record.  The  data  may  be  changed  here 
for  this  particular  bindery  order,  but  will  not  be  permanently 
changed  in  the  bindery  instructibn  record.  Tb  make  a  permanent 
change,  the  user  must  edit  the  actual  instruction  record,  not 
the  bindery  queue  record,  via  Bindery  Add/Edit. 

The  cursor  will  be  positioned  at  the  prompt,  "What  do  you  want  tb 
edit?"  Note  that  the  commands  valid  on  the  first  screen  of 
the  bindery  queue  record  (apprOve,  delete,  postpone,  etc.)  are 
not  relevant  here;  the  user  may  only  edit  the  data  here.  The 
user  will  input  the  reference  number  of  the  data  element  s/he 
wishes  to  work  on,  and  the  cursor  will  then  be  positioned  over 
that  data  for  overwriting  or  acceptance.  This  process  will 
continue  until  the  user  indicates  completion  with  a  <RETURN>.  If 
there  is  another  screen  of  questions,  it  will  appear  at  this 
time;  otherwise,  the  system  will  then  display  the  first  screen 
of  the  next  bindery  queue  record  in  the  user's  retrieval  set. 
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Once  a  bindery  notice  is  generated,  and  a  shipment  is  sent  to  the 
binder,  the  bindery  queue  record  will  still  be  available  for  the 
user  to  review: 


BINDERY  QUEUE  SCREEN  1 

What  do  you  wish  to  do? 

TITLE:  Bulletin  of  the  American  Society  for  Information  Science 

BINDERY:  Capitol  Bindery  Group  CATEGORY:  Bound 

ACCOUNT  #:  1234567890  SHIPMENT  #:  1  SHIP  DATE:  06/30/84 

BINDERY  UNIT:  VOLUME  18  1982 


REF 

VOLUME 

NUMBER 

MONTH 

YEAR 

COPY 

STATUS 

1  . 

18 

1 

JAN 

1982 

1 

AT  BINDERY 

2. 

18 

2 

MAR 

1982 

1 

AT  BINDERY 

3. 

18 

3 

MAY 

1982 

1 

AT  BINDERY 

4. 

18 

4 

JUL 

1982 

1 

AT  BINDERY 

5. 

18 

5 

SEP 

1982 

2 

AT  BINDERY 

6. 

18 

6 

NOV 

1982 

1 

AT  BINDERY 

7.  SPECIAL  INSTRUCTIONS: 


V-Approve  X=Delete  E=Edit  A=Add  item  P=PostpOne  B=Browse  queue  F=Forward 


This  record  will  remain  in  the  queue  for  m0nit6ring  of  bindery 
status,  for  potential  generation  of  overdue  notices  to  the 
bindery,  and  until  the  new  bound  volume  is  checked  in.  The 
record  is  no  longer  editable,  but  the  user  may  page  through  the 
record  for  informational  purposes. 

Note  that  although  each  individual  issue  is  still  listed  on 
the  above  screen  as  "At  Bindery,"  these  item  records  no 
longer  exist  in  ILS.  Rather,  they  have  been  replaced  by  the 
"bindery  unit"  item  record  for  Volume  18,  1982.  The  online 
catalog  will  only  list  this  one  item,  not  the  individual  issues, 
as  "At  Bindery." 

Once  the  newly  bbund  volume  is  received,  it  may  be  checked-in 
via  the  serials  check-in  function.  At  that  time,  this  bindery 
queue  record  listed  above  will  be  automatically  deleted  from 
the  system.  F6r  more  detail,  see  the  section  of  this  document 
on  the  CHECK-IN.  MODULE. 
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-*L  -  -i 


A 


BINDERY  QUEUE 


SCREEN  1 

What  do  you  wish  to  do? 


TITLE:  Journal  of  ambitious  enumeration  schemes 
BINDERY:  Capitol  Bindery  Group  CATEGORY:  Bound 
ACCOUNT  #:  1234567890  SHIPMENT  #:  3  SHIP  DATE: 

BINDERY  UNIT:  VOLUME  3  SECTION  1  PART  1  NUMBER  1  1983 

REF  VOL  SEC  PT  NO  ISS  DATE  DELETE  ITEM: 


1 . 

3 

1 

1 

1 

1 

01 /01 / 83 

2. 

3 

1 

1 

1 

2 

01 /02/83 

3. 

3 

1 

1 

1 

3 

01/03/83 

4. 

3 

1 

1 

1 

4 

01 /04/83 

5. 

3 

1 

1 

1 

5 

01 /05/83 

6. 

3 

1 

1 

1 

6 

01 /06/83 

7. 

3 

1 

1 

1 

7 

01 /07/83 

8. 

3 

1 

1 

1 

8 

01 /08/83 

9. 

(MORE) 

3 

1 

1 

1 

9 

01 /09/83 

V=Approve  X=Delete  E=Edit  A=Add  item  P=Postpone  B=Browse  queue  F=Forward 


The  above  screen  is  the  bindery  queue  record  for  those  titles 
with  an  enumeration  of  four  or  mOre  levels.  The  data  is  more 
compact,  and  abbreviated  where  possible  t6  fit  as  much 
significant  data  as  possible  on  one  screen.  The  user  interface 
behaves  the  same  as  described  above,  except  that  the  SPECIAL 
INSTRUCTIONS  data  element  will  not  appear  until  the  user  has 
paged  through  the  items  in  the  screen  window  to  the  end  of 
the  issue  list.  Subsequent  screens  of  instructional  questions 
will  also  be  displayed  upon  approval  of  the  first  screen. 


OUTPUTS 


All  outputs  listed  below  will  be  specifically  formatted  with 
the  Pentagon  librarians  during  the  implementation  cycle.  The 
following  list  enumerates  the  data  elements  required  for  each 
output,  but  does  not  detail  a  specific  format  for  reporting. 
Each  report  also  must  be  prioritized  for  implementation. 


BINDERY  ACTIVITY  REPORT 

Thhis  will  be  an  online  report  suitable  for  screen  printing. 
The  user  will  define  start  and  end  dates  for  the  reporting 
period.  Data  elements  will  include: 

Number  of  title  sent  to  the  bindery 
Number  of  title  received  from  the  bindery 
Number  of  titles  overdue  from  the  bindery 
Average  turnaround  time  between  date  sent  to  bindery 
and  date  received  frOm  bindery 


BINDERY  NOTICE 

This  is  the  printed  notice  which  will  be  sent  to  the  bindery  with 
multiple  titles  to  be  bound.  A  separate  notice  will  be  generated 
for  each  bindery.  The  notice  must  include  the  following  header 
data: 

Bindery  name  and  address 
Library  name  and  address 
Customer  account  number 
Date  shipped 
Shipment  number 

For  each  title  being  shipped  for  processing,  the  notice  will 
report: 

Issue  enumerations  and  dates 

Bindery  unit  enumeration  and  date  for  spine 

User-defined  data  for  binding  instructions  (varies) 


OVERDUE  BINDERY  NOTICE 


This  is  a  printed  notice  to  sent  to  a  binder  who  is  late  in 
returning  processed  titles.  The  notice  must  include: 

Library  name  and  address 
Vendor  name  and  address 
Customer  account  number 
Shipment  date 
Shipment  number 
Free  text  message 

For  each  delinquent  title,  the  notice  will  list: 

Issue  enumerations  and  dates 
Bindery  unit  enumeration  and  date 
User-defined  data  (varies) 


BINDERY  CANDIDATES  REPORT 

This  printed  report  will  list  titles  and  issues  which  are 
predicted  for  bindery  shipment  but  are  not  yet  sent.  The  report 
is  intended  to  assist  staff  in  pulling  items  from  the  shelves 
for  shipment.  The  report  will  include  the  same  data  as  in  the 
bindery  queue  records  illustrated  above.  The  report  may  be 
sbrted  either  by  title  or  call  number.  For  each  title  listed, 
the  following  data  will  be  reported: 

Issue  enumeratibns  and  dates 
Location  (if  present  in  copy  record) 

Copy  information 
Availability 
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VENDOR  FILE  STRUCTURES 


The  ILS  Serials  Control  Subsystem  will  include  two  vendor 
information  files.  These  files  will  be  designed  to  be  used  by 
the  Serials  Control  Subsystem  as  well  as  other  ILS  subsystems 
such  as  Acquisitions  and  Property  Management.  The  term  "vendor" 
is  used  generically  to  include  all  suppliers,  publishers, 
jobbers,  associations,  donors,  exchange  sources,  etc.  The  first 
file,  the  Vendor  File,  will  be  used  for  the  storage  of  vendor 
registration  information,  such  as  vendor  name,  point  of  contact, 
telephone  number,  etc.  The  second  file,  the  Vendor  Parameter/ 
Status  File,  will  store  each  vendor's  parameterized  data,  such 
as  claim  and  cancellation  intervals.  This  file  will  also  store 
each  vendor's  performance  statistics. 

The  Vendor  File  will  be  created  through  the  Vendor 
Registration  function  which  will  use  software  that  is  very 
similar  to  the  current  ILS  Patron  Registration  function  software 
Certain  questions  will  be  required  for  each  vendor,  but  other 
questions  may  be  added,  edited,  and  deleted  by  the  library 
staff.  The  internal  structure  of  the  vendor  data  will  also 
allow  the  library  staff  to  define  different  vendor  address 
formats  for  the  various  outputs  of  the  Serials  Control  Subsystem 

Vendor  registration  information  will  be  separated  from 
parameter/status  information  for  the  following  reasons: 

1 .  In  order  to  allow  certain  data  elements  to  be  repeatable 
a  separate  file  is  needed  so  that  the  patron  registration 
software  may  be  adapted  for  vendor  registration.  The 
software  cannot  presently  support  repeatable  data 
elements  for  individual  registration  questions. 

2.  It  is  desirable  to  keep  performance  data  in  a  separate 
file  since  this  data  is  manipulated  by  the  system  rather 
than  by  the  user.  Vendor  performance  statistics  will  be 
accessible  to  the  user  through  displays  and  MIS  reports, 
but  will  not  be  subject  to  user  edit.  Vendor  parameters 
will  be  initialized  by  the  user  and  changed  infrequently 
through  a  function  shared  with  the  Acquisitions  Subsystem, 
the  Vendor  Parameter/Status  function.  However,  the  system 
will  have  constant  interaction  with  these  parameters. 

3.  Parameterized  data,  performance  data,  and  "group  vendor 

ID"  data  may  not  apply  to  all  types  of  vendors.  The  "group 
vendor  ID"  is  the  method  by  which  a  vendor  record  may  be 
linked  to  other  vendor  records  to  indicate  that  another 
company  handles  a  particular  vendor's  stock.  For  example, 
a  publisher  may  be  listed  in  the  vendor  files  as  a  direct 
source,  but  may  also  have  several  jobbers  who  handle  that 
inventory.  The  grr  ;p  vendor  ID  will  be  repeatable  to 


indicate  a  choice  of  alternative  sources.  However,  the 
group  vendor  ID  data  is  unnecessary  for  certain  vendor 
categories,  such  as  "Donor."  More  important,  other  ILS 
subsystems  such  as  Property  Management  and  Acquisitions 
will  share  the  Vendor  Pile  with  the  Serials  Control 
Subsystem.  While  all  subsystems  with  vendors  will  need  to 
store  vendor  registration  information,  not  all  subsystems 
will  require  parameterized  data,  performance  data,  or 
group  vendor  ID  data. 

Because  multiple  titles  are  often  acquired  from  a  single 
source,  the  storage  of  source  information  in  the  Vendor  File  will 
reduce  data  redundancy  across  bibliographic  records  and  will 
thereby  eliminate  unwanted  expansion  of  the  master  bibliographic 
file.  Changes  in  vendor  addresses,  parameters,  etc.,  can  be 
accomplished  much  more  rapidly  and  efficiently  by  editing  the 
data  in  either  the  Vendor  Registration  function  or  the  Vendor 
Parameter/Status  function  instead  of  in  each  affected  serial 
record. 

Just  as  the  ILS  presently  supports  the  creation  of  multiple 
types  of  patrons,  the  proposed  Vendor  Registration  function  will 
allow  the  user  to  define  multiple  types  of  vendors.  This  vendor 
type  data  element  will  be  called  the  Vendor  Category.  The  Serials 
Conrol  Subsystem  will  provide  some  default  categories,  such  as 
"Publisher"  and  "Jobber".  The  user  will  be  able  to  create 
individual  questions  for  each  type  of  vendor  category,  in 
addition  to  the  questions  which  are  required  by  the  system.  The 
Define  Address  (/DA)  function  will  be  expanded  to  allow  the  user 
to  work  with  either  the  Patron  File  or  the  Vendor  File  in 
defining  different  addresses  for  various  ILS  outputs. 

When  a  new  vendor  is  registered,  the  system  will 
automatically  generate  an  internal  Vendor  ID  (VE)  which  will 
serve  as  a  unique  identifier  for  the  vendor  in  all  ILS  software. 
The  Vendor  ID's  will  serve  as  the  link  between  the  serial  records 
and  the  vendor  files. 

For  discussion  purposees,  the  Vendor  File  will  be  referred  to 
as  APV,  and  the  Vendor  Parameter/Status  File  will  be  referred  to 
as  APV1 .  A  decision  has  not  yet  been  made  by  Online  as  to 
whether  APV1  will  carry  both  acquisitions  and  serials  parameter/ 
status  information  or  whether  the  information  will  be  carried  in 
separate  files,  such  as  “PV1  and  APV2.  The  data,  however,  will 
have  the  same  structure  whether  it  is  stored  in  one  or  two  global 
files.  Storing  the  information  in  one  file  will  reduce  the 
proliferation  of  files  in  the  ILS.  Storing  the  information  in 
separate  files  would  help  avoid  the  creation  of  an  extremely 
large  file  for  vendor  parameter/status  information.  There  would 
be  no  difference  in  programming  effort  for  one  file  versus  two 
files. 
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PV 


Vendor  File 


This  sample  Vendor  Registration  File  illustrates  the  data 
elements  which  will  be  required  by  the  system.  Other  data 
elements  pertaining  to  individual  vendor  categories  may  be 
defined  at  the  user's  option  in  the  Vendor  Question  Definition 
(/VQ)  module.  This  module  will  be  similar  to  the  present  ILS 
Patron  Question  Definition  (/PQ)  module.  The  Define  Address 
(/DA)  function  of  ILS  will  be  modified  so  that  both  vendor  and 
patron  addresses  may  be  defined  for  various  ILS  outputs. 

APV="Vendor  File” 

APV("")=Last  Vendor  ID  (VE)  Used 

APV(VE, 1 )=Vendor  Name  (Required) 

APV(VE,2)=Vendor  Category  (Required) 

APV(VE, 3)=Small  Business  Indicator — YES/NO  (Required  for 
Acquisitions) 

APV(VE, 4)=0rganization  Level — Selected  from  system  dictionary 
entries  to  distinguish  vendors  with  the  same  name 
(Required) 

APV(VE, 5)=Status — Selected  from  dictionary  entries  such  as 
"Active",  etc.  (Required) 


Vendor  Parameter/Status  File 


APV1 


The  following  illustrates  the  structure  of  the  Vendor 

Parameter/Status  File  as  it  will  exist  if  serials  and 

acquisitions  data  are  grouped  together. 

APV1="Vendor  Parameter/Status  File" 

APV1 (VE)=[Priraary  group  vendor]  [Secondary  group  vendor] 

APV1 (VE,0)=[VE]  [VE]  [VE]  }  Up  to  MIIS  string  limit  (@  200 

characters  or  60  Vendor  ID's)  from  which  to  choose 
the  primary  and  secondary  group  vendor  to  handle 
this  vendor's  orders.  Updated  through  the  Vendor 
Parameter/Status  module. 

“PV1 (VE, 1 ,P0ID)=[nP0]  [NPA]  [NPA]  }  This  node  represents  a  link 
to  the  internal  purchase  order  ID  (POID)  and  the 
library-defined  numbers  for  a  purchase  order  (NPO) 
and  its  amendments  (NPA).  The  node  will  support  up 
to  the  MIIS  string  limit  (@  200  characters  or  60 
NPAs  if  applicable);  otherwise,  it  will  be  null. 

APV1 (VE, 2)=[ciaim  Form  for  Monographs]  [Claim  Form  for  Serials] 
[Default  Claim  Period  for  Monographs]  [Default  Claim 
Period  for  Receipt  of  1st  Issue  of  a  Serial 
Subscription]  [Default  Claim  period  for  Receipt  of 
2nd  and  Subsequent  Issues  of  a  Serial  Subscription] 
.Default  Cancellation  Interval  for  Monographs] 

Default  Cancellation  Interval  for  Serials]  [Default 
Shipment  Code  (STC)]  [Maximum  Order  $]  [Maximum 
Order  Number  (of  Items)]  [Maximum  Order  Number  (of 
Subscriptions)]  [Minimum  Order  $]  [Minimum  Order 
Number  (of  Items)]  [Minimum  Order  Number  (of 
Subscriptions)]  [Type  of  Order  Form]  [Discount 
Coupon  Flag]  [standard  Discount  Flag] 

APV1 (VE, 3) =[ Value; Value; Value. .. ]  [No.  of  CouponsjNo.  of 
CouponsjNo.  of  Coupons...]  )  These  two  stacked 
pieces  may  total  up  to  the  MIIS  string  limit.  Each 
dollar  value  in  the  first  piece  will  correspond 
to  a  number  in  the  second  piece.  Together  they 
will  indicate  how  many  coupons  of  a  certain  dollar 
value  are  in  the  library's  possession. 

APV(VE,4)=[standard  Threshold  Amount;Standard  Threshold  Amount; 

Standard  Threshold  Amount...]  [Flag/Standard  Discount 
Rate;  Flag/Standard  Discount  Rate;  Flag/Standard 
Discount  Rate  .  .  . ]  }  These  two  stacked  pieces  may 
total  up  to  the  MIIS  string  limit.  Each  threshold 
amount  will  have  a  corresponding  discount  rate.  For 
example,  an  order  totaling  $100  to  $199*99  may  entitle 


the  library  to  a  discount  rate  of  10?,  while  an  order 
$200  or  above  may  allow  a  discount  rate  of  15?.  A 
flag  will  correspond  to  each  Standard  Discount  Rate 
to  indicate  whether  the  rate  is  a  percentage  of  the 
total  order  or  a  fixed  monetary  amount. 

PV1 (VE, 5 )=  .Total  No.  of  Purchase  Orders  (NPOs)]  [Last  NPO  sent] 
.Last  NPO  Date]  [No.  of  Outstanding  NPOs] 

PV1 (VE,6)=[Total  No.  of  Purchase  Order  Amendments  (NPAs)]  [Last 
NPA  sent]  [Date  of  Last  NPA]  [No.  of  Outstanding  NPAs] 

PV1 (VE,7)=[Avg.  Turn  Around  Time  from  Order  Date  to  Date  Reed. 

(DRX)  for  Monos.]  [Avg.  Turn  Around  Time  from  Order 
Date  to  Date  Reed.  (DRX)  for  1st  Issue  of  New  Serial 
Subscription]  [Avg.  Difference  Between  Encumbered  and 
Actual  Prices]  [No.  of  Backorders]  [No.  of  Claims — 
Monographs]  [No.  of  Filled  Claims — Monographs] 

[No.  of  Returned  Items  (Monos.)]  [No.  of  Damaged 
Issues  (Serials)] 

PV1 (VE,8)=[SID]  [SID]  [SID]  1  Up  to  MIIS  string  limit  (@  200 
characters  or  60  subscription  ID's  (SID's)  which 
serves  as  a  list  of  the  library’s  serial  subscriptions 
which  are  supported  by  this  vendor. 

PV1 (VE,8, YYMMDD)=[No.  of  Claims  (Current)]  [No.  of  Filled  Claims 
(Current)]  [No.  of  Follow-ups  (Current)]  [No.  Claims 
Declared  Missing  (Current)]  [No.  of  Filled  Claims 
'Retrospective)]  [No.  of  Follow-ups  (Retrospective)] 
No.  of  Claims  Declared  Missing  (Retrospective)] 

No.  of  Days  to  Fill  Claim  (Retrospective)] 


VENDOR  REGISTRATION 


The  Serials  Control  Subsystem,  along  with  the  Acquisitions 
Subsytem  and  the  Property  Management  Subsystem,  must  accommodate 
the  entry  of  vendor  registration  information.  The  ILS  Patron 
Registration  and  Patron  Question  Definition  software  will  be 
modified  to  support  vendor  registration.  An  outline  in  the  form 
of  proposed  ILS  screens  follows. 


SERIALS  CONTROL  SUBSYSTEM 
VENDOR  REGISTRATION 

VENDOR  NAME:  R.  R.  Bowker  Company 
VENDOR  CATEGORY:  ? 


INDEX  CATEGORY  NAME 


1  PUBLISHER 

2  JOBBER 

(END)  Enter  an  index  number  or  a  vendor  category: 


The  previous  screen  illustrates  that  the  system  prompted  for 
VENDOR  NAME  and  that  the  user  entered  "R.  R.  Bowker  Company". 

The  system  performed  a  syntax  check  and  searched  the 
cross  index  of  vendor  names  for  a  match  of  the  user's  input.  No 
match  was  found,  but  if  one  or  more  matches  had  been  located, 
the  system  would  have  displayed  a  table  of  the  matches.  The  user 
would  have  been  able  to  select  one  of  the  table  entries  or  would 
have  input  the  word  "NEW"  to  indicate  that  this  vendor  name  was 
not  related  to  any  of  the  matches.  If  a  table  entry  had  been 
selected,  the  system  would  have  displayed  all  of  that  vendor's 
registration  information. 

After  the  vendor  name  "R.  R.  Bowker  Company"  was 
entered,  the  system  prompted  the  user  for  VENDOR  CATEGORY.  The 
user  input  a  question  mark,  and  the  system  displayed  the  two 
vendor  categories  which  were  defined  to  the  system. 


SERIALS  CONTROL  SUBSYSTEM 
VENDOR  REGISTRATION 


VENDOR  NAME:  R.  R.  Bowker  Company 
VENDOR  CATEGORY:  Publisher 
STATUS:  Active/  __ 

ORGANIZATION  LEVEL: 

SMALL  BUSINESS  INDICATOR:  NO 
CONTACT  PERSON: 

EDITORIAL  ADDRESS: 

EDITORIAL  CITY: 

EDITORIAL  STATE: 

EDITORIAL  ZIP: 

EDITORIAL  TELEPHONE: 

BUSINESS  ADDRESS: 

BUSINESS  CITY: 

BUSINESS  STATE: 

BUSINESS  ZIP: 

BUSINESS  TELEPHONE: 


The  previous  screen  illustrates  that  the  system  has 
displayed  all  of  the  question  prompts  for  the  Publisher  category. 
The  Status,  Organization  Level,  and  Small  Business  Indicator 
questions  are  required  questions  and  are  therefore  listed  before 
the  other  questions.  At  the  Status  prompt,  the  user  must  choose 
one  of  the  dictionary  entries  (Active,  Inactive,  Out  of  Business) 
defined  in  the  Vendor  Question  Definition  Module.  The  vendor’s 
status  is  vital  to  the  system  in  that  it  determines  whether  or 
not  ILS  users  may  place  subscription  orders  with  the  vendor. 

The  Organization  Level  is  a  free-text  data  element  which  helps 
Serials  Control  Subsystem  users  to  distinguish  among  vendors  with 
the  same  name.  An  input  to  this  question  might  be  "Eastern 
Division"  or  "Primary  Order  Source",  etc.  The  Small 
Indicator  must  be  either  "YES"  or  "NO".  This  data  element 
is  jsed  in  subscription  ordering.  The  remaining  questions 
are  user-defined,  and  each  question  may  or  may  not  be  required. 
For  example,  in  the  previous  screen  the  library  staff  created  two 
sets  of  address  questions — one  for  editorial  correspondence,  the 
other  for  subscription  inquiry. 

When  the  user  has  responded  to  each  question  the  system  will 
prompt  "FILE  VENDOR?  "  and  the  user  will  respond  with  YES  or  NO. 

A  Vendor  Delete  function  will  allow  users  to  delete  vendors 
from  the  database  who  have  no  outstanding  business  with  the 
library  in  any  capacity — acquisitions,  property  management,  or 
serials. 


VENDOR  PARAMETERS 


Once  a  new  vendor  has  been  registered  in  the  Vendor 
Registration  function,  the  system  will  immediately  transfer  the 
user  to  the  Vendor  Parameter/Stat as  function  for  the  input  of 
default  parameters. 


SERIALS  CONTROL  SUBSYSTEM 
VENDOR  PARAMETER/STATUS 


Edit  Which  Field'5 


ADDITION  OF  VENDOR  PARAMETER  INFORMATION  FOR 
R.  R.  BOWER  COMPANY 


1) 

CLAIM  PER. -1ST  ISSUE: 

7) 

MAX . 

DOLLAR 

AM". 

2) 

SUBSEQ.  CLAIM  PER.: 

fl) 

MIN. 

DOLLAR 

AVT. 

3) 

#  CLAIMS: 

9) 

MAX. 

a  svpr, 

.  : 

4) 

CLAIM  FORM: 

10) 

MIN. 

h  S7RD, 

,  ; 

5) 

CANCEL.  INTERVAL: 

11) 

ORDER 

FORM: 

6) 

SHIPMENT  CODE: 

The  following  information  describes  each  question  in  more 

detail: 

1)  CLAIM  PER. -1ST  ISSUE:  The  Claim  Period  for  First  Issue 
Receipt  will  indicate  the  period  of  time  the  system  should 
wait  before  the  claim  process  should  be  started  in  the  case 
that  the  library  has  never  received  the  first  issue  of  a  new 
subscription. 

2)  SUBSEQ.  CLAIM  PER.:  The  Subsequent  Claim  Period  will  indicate 
the  period  of  time  the  system  should  wait  before  the  claim 
process  is  started  for  any  issue  other  than  the  first  of  a 
subscription.  This  data  element  will  usually  be  shorter 

than  that  for  Claim  Period  for  First  Issue  Receipt,  as  it 
takes  longer  for  a  new  subscription  to  begin  than  it  does  for 
subsequent  issues  to  arrive. 

3)  #  CLAIMS:  Number  of  Claims  will  contain  the  maximum  number  of 
claims  the  system  should  generate  for  an  issue. 

4)  CLAIM  FORM:  Claim  Form  will  allow  the  user  to  indicate 
whether  this  vendor's  claims  should  be  made  in  writing  or 
if  a  telephone  call  will  suffice. 

5)  CANCEL.  INTERVAL:  Cancellation  Interval  indicates  the  length 
of  time  after  the  Claim  Period  for  First  Issue  Receipt  has 
passed  before  the  system  isues  a  cancellation  notice  for  the 
subscription. 

6)  SHIPMENT  CODE:  The  Default  Shipment  Code  will  allow  the  user 
to  indicatea  mode  of  shipment  from  the  system  dictionary  of 
shipment  codes.  The  user  may  also  enter  a  new  shipment  code 
to  the  dictionary  at  this  prompt. 

7)  MAX.  DOLLAR  AMT.:  The  Maximum  Dollar  Amount  will  indicate  the 
monetary  ceiling  for  any  order  to  this  vendor. 

8)  MIN.  DOLLAR  AMT.:  The  Minimum  Dollar  Amount  will  indicate  the 
minimum  monetary  amount  for  an  order  to  this  vendor. 

9)  MAX.  §  SUBS.:  The  Maximum  Number  of  Subscriptions  will 
reflect  the  limit  of  subscriptions  whicl  may  be  placed  on  one 
order  to  this  vendor. 

10) MIN.  §  SUBS.:  The  Minimum  Number  of  Subscriptions  will 
reflect  the  lowest  number  of  subscriptions  which  may  be 
placed  on  one  order. 

1 1 ) 0RDER  FORM:  The  Type  of  Order  Form  will  allow  the  user  to 
select  the  preferred  order  form  for  this  vendor  from  the 
system  dictionary. 


VENDOR  PERFORMANCE  STATISTICS 


Once  a  vendor  has  become  active  in  the  system,  the  user  may 
also  access  the  Vendor  Parameter/Status  function  to  obtain  a 
''tatistical  report  of  the  vendor's  performance. 


SERIALS  CONTROL  SUBSYSTEM 
VENDOR  PARAMETER/STATUS 

VENDOR:  ? 


Enter  One  of  the  Following: 


Vendor  Name  (Full  or  Partial) 
Vendor  ID  (VE) 

/VE  to  Register  a  Vendor 


The  previous  screen  indicates  that  the  user  has  entered  a 
question  mark  at  the  "VENDOR:  "  prompt.  The  system  has  responded 
that  the  user  may  enter  either  a  full  or  partial  vendor  name,  an 
internal  vendor  ID  (VE),  or  may  "slash"  to  the  Vendor 
Registration  function  to  enter  a  vendor  who  is  new  to  the  system. 
The  following  screen  illustrates  how  a  user  may  access  the 
vendor's  performance  statistics. 


SERIALS  CONTROL  SUBSYSTEM 
VENDOR  PARAMETER/STATUS 

VENDOR:  R.  R.  Bowker  Company 

ACCESS  P) ARAMETER  OR  S)TATUS  DATA9  S 


The  status  report  will  appear  as  follows: 


SERIALS  CONTROL  SUBSYSTEM 
VENDOR  PARAMETER/STATUS 


Vendor  Status  Information  for 
R.  R.  Bowker  Company — May  1,  1984 

The  following  statistics  reflect  activity  from  MM/YY/DD 


Total  #  P.0. ' s: . 25 

Last  P.0.  #:  ...  MDA-P0-10098 

Total  #  P.0.  Amends.:  .  .  .  .  1 
Last  P.0.  Amend.:  MDA-P0-1 0047-A 
No.  of  Non-Serial  Claims:  .  .  1 

No.  of  Backorders: . 0 

No.  of  Returned  Items:  ....  2 


No.  of  Damaged  Serial  Issues:  0 
No.  of  Subscriptions:  .  .  .  .39 


No.  Outstanding:  2 
Date:  09/27/84 
No.  Outstanding:  0 
Date:  09/21/83 
No.  Filled:  .  .  .10 


Average  Days  from  Order  to  Receipt  of  First  Copy: . 20 

Average  Difference  Betwen  Encumbered  and  Actual  Price:  .  +$10.00 


PRESS  <RETURN>  TO  CONTINUE 


The  Vendor  Status  Report  includes  both  serial  and 
acquisitional  performance  information  as  both  subsystems  will 
share  the  Vendor  Parameter/Status  function.  A  description  of 
each  element  of  the  report  follows: 

TOTAL  #  OF  P.O.'S:  This  data  element  will  contain  the  number 
of  purchase  orders  sent  to  this  vendor  from  the  start  of  the 
statistical  recording  period  to  the  time  of  the  compilation  of 
the  report. 

NO.  OUTSTANDING:  Will  contain  the  count  of  purchase  orders  which 
have  not  yet  been  filled  by  this  vendor. 

I  AST  P.0.  #:  The  library-assigned  number  of  the  last  purchase 
order  which  was  sent  to  this  vendor. 

DATE:  The  date  of  the  last  purchase  order  sent  to  this  vendor. 

TOTAL  #  P.0.  AMENDS.:  This  data  element  will  contain  the 
number  of  amendments  (additions/changes)  to  purchase  orders 
which  were  sent  to  this  vendor  from  the  start  of  the 
statistical  recording  period  to  the  time  of  the  compilation  of 
the  report. 


NO.  OUTSTANDING:  Will  contain  the  count  of  purchase  order 
amendments  which  have  not  yet  been  filled  by  this  vendor. 


LAST  P.O.  AMEND.:  The  library-assigned  number  of  the  last 
purchase  order  amendment  which  was  sent  to  this  vendor. 


DATE:  The  date  of  the  last  purchase  order  amendment  sent  to  this 

vendor. 

NO.  OF  NON-SERIAL  CLAIMS:  Will  contain  the  number  of  claims 
sent  to  this  vendor  for  items  other  than  serial  issues. 

NO.  FILLED:  Will  contain  the  number  of  non-3erial  claims  which 
were  filled  by  this  vendor. 

NO.  OF  BACKORDERS:  This  data  element  will  reflect  the  number 
of  items  which  were  ordered  from  this  vendor,  but  which 
cannot  be  forwarded  to  the  library  in  the  near  future 
because  of  a  temporary  stock  depletion. 

NO.  OF  RETURNED  ITEMS:  This  data  eleent  will  contain  the  number 
of  non-serial  items  which  had  to  be  returned  to  this  vendor 
due  to  shipping  errors,  item  damage,  etc. 

NO.  OF  DAMAGED  SERIAL  ISSUES:  Will  contain  the  number  of 

serial  issues  the  library  has  received  from  this  vendor  which 
were  in  unsatisfactory  condition. 

NO.  OF  SUBSCRIPTIONS :  Will  contain  the  number  of  serial 
subscriptions  supplied  to  the  library  by  this  vendor. 

AVERAGE  DAYS  FROM  ORDER  TO  RECEIPT  OF  FIRST  COPY:  Will  contain 
the  average  number  of  days  it  takes  this  vendor  to  deliver 
the  first  issue  of  a  new  subscription. 

AVERAGE  DIFFERENCE  BETWEEN  ENCUMBERED  AND  ACTUAL  PRICE:  Will 
contain  the  positive  or  negative  U.S.  currency  amount 
reflecting  the  discrepancy  between  how  much  the  library 
budgeted  for  each  item  or  subscription  and  the  actual 
amount  paid. 


The  user  will  not  be  able  to  add  to,  edit,  or  delete  from 
the  data  presented  on  the  Vendor  Status  Report.  It  is  intended 
to  serve  as  a  vendor  performance  measurement  tool  which  will 
enable  the  library  staff  to  evaluate  the  system-compiled 
statistics  for  each  vendor's  service  to  the  library. 
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CAS  SCREENS 


The  following  pages  illustrate  our  proposed  designs  for  new 
serials  card  images  and  holdings  displays  for  CAS.  The  current 
CAS  screens  for  serial  records  need  to  be  enhanced  to  accommodate 
flexible  enumeration  patterns,  consolidated  holdings  statements, 
display  of  several  different  formats  per  title,  and  browsing 
issue  da+a  in  more  detail.  Each  page  lists  a  screen  and  an 
explanation  of  the  new  display.  Alternatives  are  listed  where 
our  designs  are  not  finalized. 


i 
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Association  of  Obsessed  Catalogers 
Bator,  Eileen  Q, 


Title  analysis  /  [sponsored  by  the]  Association  Of  Obsessed  Catalogers 
and  edited  by  Eileen  Q.  Bator. 

Washington  :  Pentagon  Press, 
v.  1  -  1982  - 

Cataloging  -  Title  analytics. 

HOLDINGS: 

HARDCOPY:  VOL.  1  -  3  ;  1982-1984 

For  more  detailed  holdings  (and  missing  issues),  press  H  for  information. 

To  search  a  specific  issue,  press  N  for  number  or  D  for  date  prompt. 

Press  /ES  to  start  a  new  search,  or  RETURN  for  the  next  record. 

CHOICE: 


Some  serials,  when  defined  in  HOldings  Add/Edit,  will  have  an 
indicator  which  specifies  tb  the  librarian  that  each  individually 
received  issue  must  be  analyzed  bibliographically.  For  open 
entries  which  are  checked-in  as  well  as  analyzed,  the  patrOn  must 
be  provided  with  access  to  both  the  serial  record  and  the 
individual  title  records.  Ideally,  both  should  be  linked.  The 
above  screen  will  be  used  as  the  first  screen  for  the  serial 
record.  It  has  no  indication  that  any  issue  is  analyzed,  but 
it  does  include  the  consolidated  holdings  statement  of  volumes 
held.  The  user  presses  'H'  to  see  the  detail  on  each  volume. 


Title  analysis. 


REF 

VOL 

DATE 

FORMAT 

STATUS 

R1 

1 

1982 

HARDCOPY 

NOT  AVAILABLE 

R2 

2 

1983 

HARDCOPY 

NOT  AVAILABLE 

R3 

3 

1984 

HARDCOPY 

AVAILABLE 

For  copy-specific  bibliographic  data,  select  a  REF  number. 

Press  /ES  to  start  a  new  search,  or  RETURN  for  the  next  record. 

CHOICE: 


This  is  the  second  screen  in  CAS  for  a  serial  record  which  is 
analyzed.  If  the  user  chose  the  'H'  option  on  the  previous 
screen,  s/he  will  see  a  list  of  volumes  checked  in.  Note  that 
each  volume  has  a  reference  Or  index  number  assigned  to  it.  If, 
at  this  point,  the  user  wishes  to  see  the  analytic  entry  for  any 
given  volume,  s/he  requests  the  'R'  number  of  that  volume  to  see 
the  individual  bibliographic  record.  Note,  also,  that  each 
volume's  circulation  status  is  displayed  only  as  "AVAILABLE"  or 
"NOT  AVAILABLE."  Since  this  is  a  volume  screen  and  not  a  copy- 
specific  screen,  circulation  data  is  not  available  at  the 
detailed  level  (On  Loan,  Due  6/6/84,  etc.).  At  this  point,  the 
user  can  only  be  told  if  at  least  one  copy  is  available;  if  no 
copy  is  available  at  all,  the  "NOT  AVAILABLE"  status  displays. 
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Association  of  Oosessed  Catalogers 
Bator,  Eileen  Q. 

Automated  library  systems  and  title  analysis:  is  our  job  any  easier?  / 
sponsored  by  the  Assocation  of  Obsessed  Catalogers  and  edited  by 
Eileen  Q.  Bator. 

Washington  :  Pentagon  Press,  1982. 

Title  analysis  ;  vol.  1. 

Automation  -  Libraries. 

Cataloging  -  Title  analytics. 

CIRCULATION  STATUS: 

COPY  #:  1  Checked  Out  DUE  DATE:  06/10/84 

COPY  h  2  Checked  Out  DUE  DATE:  07/01/84 

Press  <RETURN>  to  display  next  item,  or 

Press  /AU  for  author,  /TI  for  title,  /SU  for  subject,  /KW  fbr  keyword  search 
CHOICE: 


Finally,  if  the  user  requested  to  see  volume  one's  analytic 
record,  by  pressing  *  1  '  at  the  prOmpt  on  the  previous  screen,  the 
system  displays  the  familiar  bibliographic  card  image  for  the 
analyzed  title. 
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PERIODICALS 


Library  Technology  Reports. 

Chicago:  American  Library  Association. 

v.  12  -  Jan.  1976  - 

Library  retains  last  10  years  only. 


Libraries  -  Periodicals. 

Information  science  -  Periodicals. 

< 

HOLDINGS: 


HARDCOPY: 

VOL. 

20 

NO. 

1 

-  VOL. 

20 

NO. 

6 

1984 

BOUND: 

VOL. 

18 

NO. 

1 

-  VOL. 

19 

NO. 

12 

1982  - 

1-983 

MICROFILM: 

VOL. 

10 

NO. 

1 

-  VOL. 

17 

NO. 

12 

1974 

-  1981 

For  more  detailed  holdings  (and  missing  issues),  press  H  for  information. 
To  search  a  specific  issue,  press  N  for  number  or  D  for  date  prompt. 

Press  /ES  to  start  a  new  search,  or  RETURN  for  the  next  record. 

CHOICE: 


The  new  serials  control  subsystem  will  include  a  different  series 
of  CAS  screens  for  serial  titles.  The  above  screen  is  the  first 

screen  a  user  will  access  when  viewing  data  f6r  a  specific 

serial.  The  screen  includes  the  usual  card  image,  which  will  not 
be  modified  for  the  new  subsystem.  HOwever,  in  place  of  the 
VIPS/Circulation  Status  at  the  bottom  of  the  screen,  the  new 
subsystem  will  include  Consolidated  Holdings  Statements  at  the 
bottom  of  the  first  serial  screen.  There  will  be  one 
consolidated  holding  statement  for  each  format,  maintained  in  a 
local  MARC  tag  and  automatically  updated  with  the  newest 
checked-in  issue  data.  The  consolidated  holding  statement  will 
be  built  with  abbreviated  enumeration  captions,  and  will 
list  the  first  and  latest  issues  received  in  check-in.  Missing 

items,  gaps  in  the  holdings,  and  claims  will  not  be  displayed  in 

this  generalized  statement.  Fbr  such  detail,  the  user  will  press 
'H'  at  the  prompt  t6  see  specific  holdings  data. 

For  sites  electing  not  to  use  serials  check-in,  the  consolidated 
holdings  statement  will  not  appear  on  the  first  screen.  These 
sites  should  add  general  holdings  information  to  the  card  image, 
such  as  the  362  and  the  590  notes  appearing  in  the  ab6ve  screen. 


82 


PERIODICALS 


Library  Technology  Repbrts. 

Chicago:  American  Library  Association. 

v.  10  -  Jan.  1974  - 

Library  retains  last  10  years  only. 


Libraries  -  Periodicals. 
Information  science  -  Periodicals. 


HOLDINGS: 


HARDCOPY: 

VOL. 

20 

NO. 

1 

-  VOL. 

20 

NO. 

6 

BOUND: 

VOL. 

18 

NO. 

1 

-  VOL. 

19 

NO. 

12 

MICROFILM: 

VOL. 

10 

NO. 

1 

-  VOL. 

17 

NO. 

12 

1984 

1982  -  1983 
1974  -  1981 


For  more  detailed  holdings  (and  missing  issues),  press  H  for  information. 
To  search  a  specific  issue,  press  N  for  number  Or  D  for  date  prompt. 

Press  /ES  to  start  a  new  search,  or  RETURN  for  the  next  record. 


CHOICE:  N  VOLUME:  13  NUMBER:  2 


The  new  serials  control  subsystem  will  retain  the  individual 
issue  search  capability  from  the  old  subsystem,  allowing  the  user 
to  search  for  a  specific  issue  either  by  date  or  number.  If  the 
user  requested  a  search  by  number,  s/he  enters  a  ’N’  at  the 
CHOICE  prompt.  The  system  then  prompts  for  each  level  of 
enumeration,  starting  at  the  first,  or  highest  level.  The  user 
is  prompted  by  the  captions  assigned  in  Holdings  Add/Edit.  The 
screen  is  not  erased  while  this  search  proceeds,  retaining  the 
general  serial  information  for  the  user.  As  soon  as  the  patron 
has  entered  all  possible  enumeration  information,  or  enters  a 
RETURN  to  indicate  no  further  dat;  is  known,  the  system  then 
displays  the  issue  data  if  it  is  found. 


! 


I 


) 
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PERIODICALS 


Library  Technology  Reports. 

Chicago:  American  Library  Association. 

v.  12  -  Jan.  1976  - 

Library  retains  last  10  years  only. 


Libraries  -  Periodicals. 
Information  science  -  Periodicals. 

HOLDINGS: 


HARDCOPY: 

VOL.  20 

NO. 

1  -  VOL. 

20  NO.  6 

1984 

BOUND: 

VOL.  18 

NO. 

1  -  VOL. 

19  NO.  12 

1982  - 

1983 

MICROFILM: 

VOL.  10 

NO. 

1  -  VOL. 

17  NO.  12 

1974  - 

1981 

VOLUME:  13 

NUMBER: 

2 

CONTAINED 

IN:  VOL.  12-13 

1 976/77 

MICROFILM 

Press  N  for 

number, 

D  for  date,  H 

for  holdings, 

/ES  t6  search. 

CHOICE: 


The  complete  holdings  data  for  the  issue  requested  is  ndw  displayed 
for  the  user  (either  exact  enumeration  or  a  "contained  in"  statement 
for  issues  either  bound  or  accumulated.  If  more  than  one  copy  of  the 
issue  is  found,  multiple  holdings  lines  would  display.  The  user  if 
finally  prompted  again  for  choice  of  action,  while  the  original 
card  image  data  is  still  retained  on  the  screen  for  informational 
purposes. 


PERIODICALS 


Library  Technology  Reports. 

Chicago:  American  Library  Association. 

v.  12  -  Jan.  1976  - 

Library  retains  last  10  years  only. 


Libraries  -  Periodicals. 

Information  science  -  Periodicals. 

HOLDINGS: 

HARDCOPY:  VOL.  20  NO.  1  -  VOL.  20  NO.  6  1984 

BOUND:  VOL.  18  NO.  1  -  VOL.  19  NO.  12  1982  -  1983 

MICROFILM:  VOL.  10  NO.  1  -  VOL.  17  NO.  12  1 974  -  1981 

For  more  detailed  holdings  (and  missing  issues),  press  H  for  information 
To  search  a  specific  issue,  press  N  for  number  or  D  for  date  prompt. 
Press  /ES  to  start  a  new  search,  or  RETURN  for  the  next  record. 


CHOICE: 


MONTH:  MARCH 


Just  as  a  patron  may  search  for  a  specific  issue  by  enumeration, 
s/he  may  also  search  by  date,  starting  with  the  highest  level  Of 
chronology  defined  in  Holdings  Add/Edit  for  that  title.  The 
system  prompts  with  the  captions  defined  for  each  level  Of 
chronology.  The  user  may  input  complete  data,  or  a  RETURN  to 
indicate  that  no  further  data  is  known  about  a  particular  level 
of  chronology.  Note,  again,  that  the  Original  card  image  is 
retained  on  the  screen  for  informational  purposes. 


PERIODICALS 


Library  Technology  Reports. 

Chicago:  American  Library  Association. 

v.  12  -  Jan.  1 976  - 

Library  retains  last  10  years  only. 


Libraries  -  Periodicals. 
Information  science  -  Periodicals. 


HOLDINGS: 

HARDCOPY: 

VOL.  20 

NO. 

1  -  VOL. 

20  NO.  6 

1984 

BOUND: 

VOL.  18 

NO. 

1  -  VOL. 

19  NO.  12 

1982 

-  1983 

MICROFILM: 

VOL.  10 

NO. 

1  -  VOL. 

17  NO.  12 

1974 

-  1981 

YEAR:  1982 

MONTH:  MAR 

CONTAINED  IN:  VOL.  18 

1982  : 

BOUND 

Press  N  for 

number, 

D  for  date, 

H  for  holdings, 

/ES  to 

search 

CHOICE: 


If  the  system  finds  a  match  for  the  date  searched,  the  complete 
holdings  data  is  displayed  for  each  match  retrieved.  The  card 
image  is  retained  for  informational  purposes,  and  the  user  is 
again  prompted  for  a  choice  of  action  td  continue  in  his/her 
search. 


PERIODICALS 


Liorary  Technology  Reports. 


REF 

VOLUME  NUMBER 

MONTH 

YEAR 

FORMAT 

STATUS 

R1 

20 

6 

JUN 

1984 

HARDCOPY 

AVAILABLE 

R2 

20 

5 

MAY 

1984 

HARDCOPY 

AVAILABLE 

R3 

20 

4 

APR 

1984 

HARDCOPY 

NOT  AVAILABLE 

R4 

20 

3 

MAR 

1984 

HARDCOPY 

NOT  AVAILABLE 

R5 

20 

2 

FEB 

1984 

HARDCOPY 

AVAILABLE 

R6 

20 

1 

JAN 

1984 

HARDCOPY 

AVAILABLE 

R7 

19 

1983 

BOUND 

AVAILABLE 

R8 

18 

1982 

BOUND 

NOT  AVAILABLE 

R9 

16-17 

1  980/81 

MICROFILM 

AVAILABLE 

RIO 

14-15 

1  978/79 

MICROFILM 

AVAILABLE 

R11 

12-13 

1976/77 

MICROFILM 

AVAILABLE 

R12 

10-11 

1974/75 

MICROFILM 

AVAILABLE 

For  copy-specific  data,  select  a  REF  number. 

Press  /ES  to  start  a  new  search,  or  RETURN  for  the  next  record. 
CHOICE:  4 


If,  on  the  first  serial  screen  (the  card  image),  the  user 
requested  to  see  detailed  holdings  information  by  pressing  'H' 
at  the  CHOICE  prompt,  this  second  screen  would  appear.  The 
holdings  data  is  listed  in  reverse  chronological  order,  starting 
with  the  checked-in  subscription  copies.  Note  that  all  data  is 
presented  in  a  column  format,  headed  with  the  caption  data 
defined  for  that  title  in  Holdings  Add/Edit.  The  patrOn'  is  able 
to  see  at  a  glance  the  history  of  receipts  and  limited  availability 
data.  To  see  mb  re  holdings,  the  user  simply  hits  RETURN  to  continue. 
To  see  more  information  about  a  specific  issue,  the  user  selects 
the  REF  number  of  that  item  to  see  a  cOpy-specific  display  (next 
page) . 

The  abOve  formatted  screen  will  be  used  for  serials  with  up  to 
three  levels  of  enumeration.  More  extensively  defined  serials 
will  be  displayed  on  an  alternative  screen,  described  below. 

Note  that  the  FORMAT  displayed  in  the  screen  is  a  site-specific 
ILS  dictionary.  Users  may  define  any  terminology  they  desire 
for  formats.  Also  note  that  where  several  copies  of  an  issue 
exist  in  different  formats  (e.g.  volume  20  is  held  in  both 
loose  issues  and  in  a  microform  edition),  the  two  formats  will 
be  interleaved  on  the  screen,  with  the  individual  issues  sorting 
and  displaying  before  the  accumulated  edition. 
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PERIODICALS 

Liorary  Technology  Reports. 


VOLUME 

NUMBER 

MONTH 

YEAR 

FORMAT 

COPY 

STATUS 

20 

3 

MAR 

1984 

HARDCOPY 

1 

ON  LOAN,  DUE  12/12/84 

20 

3 

MAR 

1984 

HARDCOPY 

2 

MISSING 

Press  /ES  to  start  a  new  search,  or  RETURN  for  more  holdings. 
CHOICE: 


This  is  the  last  screen  a  user  will  get  t6  in  a  serials  search, 
displaying  copy-specific  data  (copy  number,  circulation  status, 
and  location  if  locations  are  present  in  the  item  record).  If 
this  had  been  an  analytic  record,  bibliographic  data  for  the  title 
would  have  appeared  (see  earlier  screens).  If  the  user  RETURN'S 
at  this  point,  the  system  will  resume  displaying  detailed  holdings 
from  the  previous  screen. 
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PERIODICALS 


LiDrary  Technology  Reports. 
PAPER  SUBSCRIPTION: 


REF 

VOL 

NO 

MONTH 

YEAR 

STATUS 

R 1 

20 

6 

JUN 

1984 

AVAILABLE 

R2 

20 

5 

MAY 

1984 

AVAILABLE 

R3 

20 

4 

APR 

1984 

NOT  AVAILABLE 

R4 

20 

3 

MAR 

1984 

NOT  AVAILABLE 

R5 

20 

2 

FEB 

1984 

AVAILABLE 

R6 

20 

1 

JAN 

1984 

AVAILABLE 

For  copy-specific  data,  select  a  REF  number. 

Press  /E3  to  start  a  new  search,  6 r  RETURN  for  the  next  record. 
CHOICE: 


An  alternative  to  the  previous  hoLdings  display  is  the  above 
example,  where  when  the  user  requests  a  second  screen  of  data  by 
entering  an  'H'  on  the  card  image  screen,  the  second  screen 
displayed  only  shows  the  current  subscription  data.  Other 
formats  (bound,  microfilm)  are  displayed  on  separate  screens 
which  are  formatted  for  their  particular  enumerations  and 
captions.  This  obviously  requires  the  user  to  enter  more 
keystrokes  to  page  through  all  the  holdings,  and  in  the  process 
s/he  may  miss  vital  data.  But  it  does  provide  a  more  readable 
screen. 

Note,  again,  that  formats  are  user-definable,  and  would  display 
terminology  which  was  defined  in  holdings  add/edit  for  that  title. 


90 


AD-A149  379 
UNCLASSIFIED 


THE  INTEGRATED  LIBRARV  SVSTEM  DESIGN  CONCEPTS  FOR  A 
COMPLETE  SERIALS  CONTROL  SUBSVSTEM(U)  ONLINE  COMPUTER 
SVSTEMS  INC  GERMANTOWN  MD  28  AUG  84  NDA903-82-C-0535 

F/G  5/2 


2/2 


NL 


PERIODICALS 


Library  Technology  Reports. 
BOUND  COPIES: 


REF 

VOL 

YEAR 

STATUS 

R1 

19 

1983 

AVAILABLE 

R2 

18 

1982 

ON  LOAN,  DUE  6/29/84 

MICROFILM: 

REF 

VOLS 

YEARS 

STATUS 

R3 

16-17 

1980-1981 

AVAILABLE 

R4 

14-15 

1978-1 979 

AVAILABLE 

R5 

12-13 

1976-1977 

AVAILABLE 

R6 

10-1 1 

1 974-1 975 

AVAILABLE 

For  copy-specific  data,  select  a  REF  number. 

Press  /ES  to  start  a  new  search,  or  RETURN  for  the  next  record. 
CHOICE: 


This  is  the  third  screen  of  holdings  data  for  a  three-format 
serial  record.  If  the  format  being  displayed  requires  more  than 
one  screen  for  display,  a  simple  RETURN  will  retrieve  the  next 
screen.  If  this  is  the  end  bf  the  microfilm  holdings,  the  system 
will,  upon  entry  of  a  RETURN,  display  the  next  defined  format 
or  will  display  the  next  bibliographic  record  in  the  patron’s 
search. 
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PERIODICALS 


Journal  of  ambitious  enumeration  schemes. 

New  York:  Convoluted  Publishers,  Inc. 
v.  1  -  Jan.  1,  1980  - 


Libraries  -  Periodicals. 

Information  science  -  Periodicals. 

HOLDINGS: 

HARDCOPY:  VOL.  1  SEC.  1  PT.  1  NO.  1  ISS.  1,  PIECE  A,  01/01/80  - 
VOL.  5  SEC.  2  PT.  1  NO.  5  ISS.  15,  PIECE  B,  05/15/84 

For  more  detailed  holdings  (and  missing  issues),  press  H  for  information 
To  search  a  specific  issue,  press  N  fbr  number  or  D  for  date  prompt. 
Press  /ES  to  start  a  new  search,  or  RETURN  for  the  next  record. 

CHOICE: 


For  serials  with  four  or  more  levels  of  enumeration,  the 
consolidated  holdings  statement  for  each  format  will  span  two 
lines.  The  first  line  will  enumerate  the  first  issue  held,  the 
second  line  will  list  the  latest  issue  received.  This  format 
will  assure  enough  space  for  unusual  numbering  schemes. 


MISCELLANEOUS  OUTPUTS 


There  will  be  other  reports  and  notices  which  should  be  supplied 
with  a  complete  serials  control  subsystem  which  may  not  be 
programmed  during  initial  implementation.  Those  outputs  should 
be  specified,  however,  to  assure  data  comprehensiveness.  As 
such  outputs  are  identified,  they  will  be  specified  with  Pentagon 
librarians. 

The  following  two  outputs  are  not  part  of  a  specific  serials 
function,  but  should  be  considered  in  the  integrated  system. 

The  first,  the  serials  holdings  list,  will  be  programmed  if  time 
and  budget  permit,  to  replace  the  Pentagon's  journal  listing. 

The  second,  the  Item  Status  function  display,  must  be  upgraded 
to  accommodate  the  new  serials  data. 


SERIALS  HOLDINGS  LIST 

This  printed  listing  should  be  generated  for  distribution  to 
reading  rooms,  departments,  or  patrbns  to  list  current  serial 
subscriptions  and  holdings.  The  list  will  be  sorted  by  serial 
title  and  will  list  the  following  data  for  each  title: 

Title 

Consolidated  holdings  statement  (or  362  field) 

Format  type 

Location  (if  present  in  item  records) 

Publisher 

Frequency 

Current  status  of  subscription 


ITEM  STATUS  REPORT 

The  present  Item  Status  function  (IS)  must  be  modified  to  display 
issue  enumeration  and  chronology  for  the  new  serials  holdings 
records.  Pentagon  librarians  will  be  consulted  to  specify  a 
suitable  format  and  pleasing  display. 
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LINKS  TO  THE  ACQUISITIONS  SUBSYSTEM 


One  of  the  major  links  between  the  Serials  ContrOl  Subsystem 
and  the  Acquisitions  Subsystem  will  be  the  processing  of  vendor 
information  for  discounts,  coupons,  and  order  placement.  The 
input  of  this  information  will  be  accomplished  through  three 
special  sections  of  the  Vendor  Parameter/Status  function. 


SERIALS  CONTROL  SUBSYSTEM 
VENDOR  PARAMETER/STATUS 

Addition  of  Vendor  Parameter  Information  for 
R.  R.  BOwker  Company 


Do  you  wish  to  enter  C)oupon  Data,  D)iscount  Data, 
Or  G)r6up  Vendor  Data? 


At  this  pbint  the  user  should  enter  a  "C",  "D",  6r  "G",  Or 
an  ILS  travel  command.  If  the  user  enters  a  "C"  for  Coupon  Data 
the  following  screen  will  be  displayed: 


SERIALS  CONTROL  SUBSYSTEM 
VENDOR  PARAMETER /STATUS 


SCREEN  1 


. VALUE 


Edit  Which  One?  _ 

Addition  6f  Coupon  Information  for 
R.  R.  Bowker  Company 

NO.  OF  COUPONS 


The  user  will  be  able  t6  enter  up  to  50  different  c6up6n 
values,  with  ten  values  bn  each  of  three  screens.  For  example, 
the  user  may  have  three  $1  coupons,  two  $5  coupons,  and  one  $10 
coupon  wich  could  be  entered  as  follows: 


VALUE 
1)  1.00 
2)  5.00 
5)  10.00 


NO.  OF  COUPONS 
3 
2 
1 


There  will  be  no  requirement  for  the  user  to  enter  the 
coupons  in  either  value  or  number  order,  nOr  will  the  user  be 
required  to  group  all  of  the  same  cbupon  value  amounts  in  One 
display  line.  To  illustrate,  the  user  may  enter  the  next  line 


4)  5.00 
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This  extra  information  would  be  compiled  with  the  other  $5 
value  information  after  filing.  Upon  redisplay,  the  information 
would  appear  in  value  order  from  highest  to  lowest: 

VALUE 

1)  10.00 

2)  5.00 

3)  1 .00 

4) 

5) 

6) 

7) 

8) 

9) 

10) 


All  of  the  value  amounts  must  be  entered  in  U.S.  currency 
format  and  will  be  stored  internally  in  U.S.  cents  for 
processing  efficiency. 

Once  the  user  indicates  that  the  coupon  data  should  be  filed 
the  system  will  return  to  the  prompt,  "Do  you  wish  to  enter 
C)oupon  Data,  D)iscount  Data,  or  G)roup  Vendor  Data?”.  If  the 
user  enters  "D"  to  input  vendor  Discount  Data,  the  following 
screen  will  be  displayed: 


NO.  OF  COUPONS 
1 
3 
3 


SERIALS  CONTROL  SUBSYSTEM 
VENDOR  PARAMETER/STATUS 


SCREEN  1 


Edit  Which  One? _ 

Addition  of  Discount  Information  for 
R.  R.  Bowker  Company 

THRESHOLD  RANGE  %  OR  $  DISCOUNT 

T5 - 

2) 

3) 

4) 

5) 

6) 

7) 

8) 

9) 

10) 


The  user  will  be  able  to  enter  up  to  20  different  discount 
threshold  ranges,  with  ten  ranges  on  each  of  two  screens.  For 
example,  the  user  may  know  that  if  the  library  places  an  Order 
with  a  value  between  $100  and  $199.99,  the  vendor  will  give  a 
ten  perent  discOunt  on  the  6rder.  Therefore,  On  the  first  line 
the  user  will  enter  "100.00-199.99"  under  the  "THRESHOLD  RANGE" 
column,  a  under  the  "%  OR  $"  column,  to  indicate  that  the 
discount  is  a  percentage  of  the  total,  and  "10"  tinder  the 
"DISCOUNT"  column  to  indicate  that  the  discount  is  ten  percent. 

There  will  be  no  requirement  fOr  the  user  to  enter  the 
discount  information  in  any  specific  Order.  However,  the 
system  will  give  an  error  message  should  the  user  enter 
conflicting  or  overlapping  discOunt  information.  Whenver  the 
discount  information  is  retrieved  by  a  user,  it  will  be 
displayed  in  threshold  Order  from  lOwest  tO  highest: 


THRESHOLD  RANGE 

%  OR  $ 

DISCOUNT 

TJ  .00-100.00 

% 

0 

2)  100.00-199.99 

% 

10 

3)  200.00-299.99 

% 

11 

4)  300.00-399.99 

% 

12 

5)  400.00-499.99 

% 

13 

6)  500.00+ 

7) 

8) 

9) 

0) 

$ 

100 

Once  the  user  indicates  that  the  discount  data  should  be 
filed,  the  system  will  return  to  the  prompt,  "DO  you  wish  to 
enter  C)oupon  Data,  D)iscount  Data,  or  G)roup  Vendor  Data?". 

If  the  user  enters  "G"  to  input  Group  Vendor  Data,  the  following 
screen  will  be  displayed: 


SERIALS  CONTROL  SUBSYSTEM  SCREEN  1 

VENDOR  PARAMETER/STATUS 


VENDOR:  ? 


Addition  of  Group  Vendor  Information  f&r 
R.  R.  Bowker  Company 


At  the  "VENDOR:  "  prompt  in  the  previous  screen,  the  user 
may  enter  a  variety  Of  conventions:  a  full  or  partial  vendor 
name,  a  vendor  ID,  or  a  special  symbol  plus  a  leter  of  the 
alphabet  to  list  the  vendor  names  which  begin  with  the  letter 
entered  by  the  user.  By  using  any  of  these  conventions  the 
user  can  create  a  subset  of  up  to  30  vendors,  10  on  each  of 
three  screens,  who  can  handle  this  vendor's  inventory.  From  this 
subset,  the  user  may  indicate  who  serves  as  this  vendor's 
Primary  Group  Vendor  and  Secondary  Group  Vendor. 


If,  for  example,  the  library  has  indicated  that  five 
different  vendors  are  able  t6  serve  as  a  group  vendor  to  this 
vendor,  the  following  screen  wbuld  appear: 


SERIALS  CONTROL  SUBSYSTEM 
VENDOR  PARAMETER/STATUS 


SCREEN  1 


VENDOR:  <Carriage  Return> 


Addition  of  Group  Vendor  Information  for 
R.  R.  Bowker  Company 


1) 

2) 

3) 

4) 

5) 

6) 

7) 

8) 
9) 

10) 


(1st  Vendor  ID)  Vendor  Name 
(2nd  Vendor  ID)  Vendor  Name 
(3rd  Vendor  ID)  Vendor  Name 
(4th  Vendor  ID)  Vendor  Name 
(5th  Vendor  ID)  Vendor  Name 


FILE?  YES 

PRIMARY  GROUP  VENDOR?  4 
SECONDARY  GROUP  VENDOR?  2 


The  previous  screen  indicates  that  the  user  has  entered  five 
group  vendors  and  then  a  carriage  return  at  the  "VENDOR:  " 
prompt.  The  user  then  entered  "YES"  at  the  "FILE?  "  prompt.  The 
system  prompted  for  the  user  to  enter  the  index  number  Of  One  Of 
the  defined  grbup  vendors  who  would  serve  as  this  vendor's 
Primary  GrOup  Vendor  (i.e.,  the  default  group  vendor  to  use  when 
Ordering  this  vendor's  material).  The  system  next  prompted  the 
user  to  enter  the  index  number  Of  one  Of  the  group  vendors  Other 
than  the  Primary  Grbup  Vendor  to  serve  as  the  Secondary  Group 
Vendor  (i.e.,  the  default  group  vendbr  to  use  when  the  Primary 
GrOup  Vendor  cannot  be  used  due  to  a  status  of  "Inactive",  etc.). 


END 
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